Use SQL-based connectors when the application is already queryable, the identity data is structured in tables, and the cost of engineering a bespoke API would slow coverage across many systems. That approach is most useful where the priority is fast governance reach across legacy and internal applications.
Why SQL-Based Connectors Fit Some Governance Use Cases Better Than Custom APIs
SQL-based connectors are strongest when the source system already exposes the data you need in relational form and the goal is to read, reconcile, and govern at speed rather than to create a bespoke integration surface. They trade application-specific design for faster coverage, less engineering overhead, and a simpler path to broad visibility across older internal systems.
The practical advantage is not just convenience. When identity or entitlement data already lives in tables, a connector can often harvest the needed records without waiting for an application team to design endpoints, version payloads, and maintain an API contract. That is why these connectors often appear in governance, inventory, and discovery workflows before custom APIs are justified.
They are usually a poor fit when the application logic itself is the point of control, when business rules must be enforced at request time, or when the source data is not safely queryable without bypassing application safeguards. In those cases, a custom API preserves intent, validation, and transaction boundaries better than direct database access.
When Direct Database Access Becomes the Better Trade-Off
Use SQL-based connectors when the data model is stable enough to query repeatedly, the database owner accepts governed read access, and the integration goal is coverage across many systems rather than deep transactional interaction with one system. They are especially useful for legacy platforms, internal apps, and reporting-style use cases where standardisation matters more than application-specific semantics.
A connector can also be the better option when engineering a custom API would create avoidable backlog. If the organisation needs to assess many systems quickly, the ability to connect once, query consistently, and reuse the same control pattern often outweighs the elegance of a bespoke service layer.
Custom APIs win when you need fine-grained business logic, user-specific workflows, or precise enforcement of authorization inside the application. They also tend to be safer when the underlying schema is volatile or when direct querying would expose more data than the integration actually needs.
What Good Practice Looks Like in the Access and Governance Layer
SQL-based connectors should be treated as governed read paths, not informal shortcuts. Access should be narrowly scoped, credentials should be rotated, and the connector should only reach the objects needed for the use case. If the connector can see more than the use case requires, the convenience gain starts to erode the governance benefit.
For teams evaluating this pattern, the key question is whether the connector is being used for structured retrieval or for application behaviour. A reporting, inventory, or reconciliation need is a good fit. A workflow that must validate input, approve an action, or write back business state usually is not. For API-centric control expectations, the OWASP API Security Top 10 remains the more relevant lens, especially where authorization and sensitive business flows are central.
When the source is database-backed and the main objective is broad governance reach, teams should favour the simplest mechanism that still preserves least privilege and auditability. When the integration begins to carry operational authority, the design should shift toward an application API with explicit control points rather than depending on a query path.
Risk and Threat Considerations
SQL-based connectors reduce build effort, but they can also create a wider read surface than intended if database permissions are too broad or if the connector is pointed at sensitive tables without strong scoping. The main risk is that a fast path to coverage becomes a fast path to overexposure, especially when many systems share similar connection patterns.
Failure mechanism: A connector with direct database access can bypass application-level checks, expose joined or historical data that was never meant for the consuming system, or inherit weak credential handling from the integration layer. In poorly governed environments, that can turn convenience into a persistent access path.
Impact: The result can be excessive data access, weaker accountability, and a harder-to-detect compromise surface if the connector credentials are reused or overprivileged. Where the data is sensitive or business-critical, the connector design should be constrained as carefully as any production API.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Direct API control over who can invoke sensitive functions matters when choosing custom APIs. |
| API6 — Unrestricted Access to Sensitive Business Flows | Custom APIs are preferable when the integration carries business action or workflow authority. | |
| Recommendation — Enforce function-level authorization in custom APIs before exposing operational actions. Protect sensitive business flows with explicit API controls and step-up checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SQL connectors rely on service credentials that must be issued and rotated safely. |
| AC-6 — Least Privilege | Connector accounts should be scoped to the minimum database access needed for governance queries. | |
| Recommendation — Manage connector credentials with defined issuance, rotation, and revocation controls. Restrict connector accounts to the minimum tables, views, and commands required. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged access rights | Database connectors can become overprivileged read paths if access is not tightly governed. |
| Recommendation — Limit and review connector access rights using privileged-access discipline. | ||
Practitioner Guidance
What to prioritise: Decide first whether the use case is read-only governance coverage or an application workflow that needs enforcement. If it is the former, SQL-based connectors are often the faster route; if it is the latter, a custom API is usually the safer long-term design.
What to verify: Confirm that the connector only needs relational data, that direct querying will not bypass important application logic, and that the database account has minimal read scope. If the answer to any of those is no, the connector is probably carrying too much responsibility.
Common mistake: Teams often choose custom APIs by default because they sound cleaner architecturally, or choose SQL connectors by default because they are faster. The better decision is to match the integration method to the control requirement, not to the preference of the implementation team.
Practitioner takeaway: Use SQL-based connectors for speed, reach, and structured retrieval, but move to custom APIs whenever the integration must enforce application behaviour, not just observe data.
Related resources from NHI Mgmt Group
- Why do organisations use OIDC instead of building custom authentication flows?
- When does regex-based secret detection become too unreliable for production use?
- Should organisations use no-code connectors or SDK-based integration for identity governance?
- When should organisations use browser redaction instead of relying on redaction APIs?