When should organisations use SQL-based connectors instead of building custom APIs?

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.

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?