Data API Builder in 2026: REST, GraphQL, and Now MCP

↓ Jump to section

Data API Builder (DAB) has been Microsoft's "point it at a database, get REST and GraphQL for free" tool since 2023. In the original form, that was already a useful 80-percent solution: spin up a container, drop a config file, skip the CRUD boilerplate that every backend engineer writes every couple of years and never enjoys.

What's changed in the last six months is that DAB picked up a third output surface: an MCP server, generated from the same config. One declaration, three protocols. That's the story worth writing about in 2026.

The boring part that still works

Start with what hasn't changed, because the unchanged parts are what make the new parts interesting.

You write a single config file. It names your data source (Azure SQL, PostgreSQL, MySQL, Cosmos DB, Microsoft Fabric SQL, Azure Synapse) and a list of entities (tables, views, or stored procedures) with role-based permissions on each. DAB reads it and exposes:

• A REST endpoint at /api/{entity} with OData-style filtering ($filter, $orderby, $select, $first, pagination).
• A GraphQL endpoint at /graphql with type-safe queries, nested relationships, and the same filter grammar.
• A Swagger UI for REST, a GraphQL playground for the schema.

A first API, end to end, looks like this:

dab init --database-type mssql --connection-string "@env('CONN')"
dab add Product --source dbo.Product --permissions "anonymous:read"
dab start

Three commands. The container serves both protocols, respects the permissions you declared, and honours the OData query grammar without you writing a single endpoint.

Latest stable is v1.7.93 (2026-04-14) and there's a v2.0 public preview (2026-03-14) already broadly usable. The project lives at github.com/Azure/data-api-builder, is MIT-licensed, and pulls daily commits from the Microsoft team. The container image is at mcr.microsoft.com/azure-databases/data-api-builder.

The MCP part that's new

Starting in v1.7, DAB also runs as a SQL MCP Server. That means the same entities you exposed as REST and GraphQL can be exposed as MCP tools to AI agents, through the same config file, the same permissions, and the same auth layer.

Out of the box, DAB generates seven MCP tools per entity you expose:

• create_records, read_records, update_records, delete_records: the obvious CRUD set.
• execute_query: parameterised SQL with the same role gating.
• describe_entity: schema introspection so the agent knows what's available.
• aggregate_records: COUNT/SUM/AVG/MIN/MAX (added in v2.0-rc).

Stored procedures get a more interesting treatment: in v2.0-rc, you can flag a sproc with mcp.custom-tool: true and it becomes a custom MCP tool with typed parameters, a description, and role-based access. The agent sees it as a dedicated tool (place_order, reconcile_batch) rather than as a generic SQL call, which is usually what you want, because the whole point of exposing a sproc is that it encapsulates logic you'd rather the agent not invent.

This slots directly into Azure AI Foundry via the Custom MCP Tool integration, or into any local agent via dab start --mcp-stdio. The config surface for MCP is a three-line block per entity; the rest of the file keeps doing what it did.

Practically: if you already have DAB running for REST and GraphQL, the MCP surface is free. If you don't, it's the same container, the same config, a different endpoint.

What you probably want to know about auth

The v2.0-rc default authentication provider changed to Unauthenticated. This is safe behind a trusted gateway; it is a footgun if you accidentally ship it to the internet. The startup logs emit a warning when entity permissions reference roles that can never activate, which at least catches the "I configured roles and then forgot to enable a provider" case.

Supported providers: Entra ID (JWT), Azure App Service EasyAuth, custom JWT via OIDC metadata, and Unauthenticated. The StaticWebApps provider is still there but the Azure Static Web Apps database connections feature was retired on 2025-11-30. If you were relying on SWA to host DAB for you, that path doesn't exist anymore. Self-host on Azure Container Apps, AKS, Container Instances, or a plain VM.

v2.0-rc also adds On-Behalf-Of (OBO) auth for SQL Server. Each user's token is swapped for a delegated SQL connection, so SESSION_CONTEXT() reflects the real caller and you can implement row-level security without emulating identity in the API layer. That's a meaningful win for compliance-heavy workloads.

Two other v2.0-rc auth niceties: role inheritance (a named-role can inherit from authenticated, which inherits from anonymous), and dab configure --show-effective-permissions which lists what each role can actually do across the whole config. Both exist because debugging permission denials used to require reading the config and doing the math in your head.

What else changed worth knowing

Permission-aware OpenAPI. /openapi/anonymous, /openapi/authenticated, /openapi/{role} emit schemas filtered by role. Useful for publishing a public API doc that doesn't leak admin-only endpoints.

Keyless PUT and PATCH for entities with autogenerated primary keys. You can upsert by business key (email, SKU) without having to round-trip the DB to get the PK first.

HTTP response compression (optimal / fastest / none). Off by default, but flipping it on matters if your GraphQL payloads are big and you're paying egress.

@akv(SecretName) variable substitution pulls secrets from Azure Key Vault directly into the config. Combined with @env(VAR_NAME), you don't have to choose between env vars and managed secrets.

.NET Aspire integration. dab init now emits an open-telemetry block wired to standard OTEL_EXPORTER_OTLP_* env vars, so an Aspire app host picks it up without extra config. If you're running DAB alongside a .NET backend, that's the path of least resistance.

dab auto-config (MSSQL only for now) generates entity definitions from pattern matching against schema metadata. Useful for the "I have 200 tables, just expose them" case, less useful when you want to curate the surface.

What's still not in the box

GraphQL subscriptions. Hasura still owns this lane. If you need real-time GraphQL, DAB is not your answer.

Batch mutations beyond nested creates. Bulk insert/update requires a stored procedure.

Full OData. The filter grammar is OData-ish. If you need true OData compliance (for clients like Power BI or Excel data models), you'll hit the ceiling.

SaaS hosting. DAB is always a container you run. Supabase and Nhost offer the same shape as a managed service with a UI; DAB gives you the engine and expects you to handle hosting. For AAD-integrated line-of-business work that has to live in your Azure tenant anyway, that's a feature. For "ship an MVP in an afternoon," Supabase is still faster.

Stored procedures in health checks. The /health endpoint checks entities but skips sprocs on purpose, because a sproc might have side effects. If your SLO depends on a sproc, you're monitoring it separately.

Gotchas worth knowing before production

The first one bit me and I'll pass it on: /health returns 403 in production mode unless you explicitly set the roles array on the health config. The naive liveness probe copied from a dev environment starts failing the moment you flip mode: production. The AKS deployment guide shows the correct shape; if you're writing Kubernetes manifests by hand, this is the one to check.

runtime.rest.request-body-strict flipped to false by default in v2.0-rc. Clients that relied on strict rejection of unknown fields need to re-opt-in.

X-Forwarded-Proto and X-Forwarded-Host are now respected for Location headers. This fixed a class of bugs where DAB behind Azure Front Door returned http:// URLs. Good news if you're on a newer version; a silent breaking change if you upgrade an app whose clients were papering over the old behaviour.

When to pick DAB up

Pick it up when your backend would otherwise be 80% repetitive CRUD endpoints: product catalogues, internal tools, admin UIs, data-heavy line-of-business apps. Pick it up in 2026 especially if you want a first-party Microsoft story for REST + GraphQL + MCP from the same config, because nobody else in the "instant backend" space has equivalent Azure AI Foundry integration.

Don't pick it up when you need real-time GraphQL subscriptions, when you want managed hosting with a UI, or when your API is mostly custom business logic that doesn't map cleanly to "tables, views, and stored procedures." For those, the answer is still either Hasura, Supabase, or a bespoke service.

Docs: learn.microsoft.com/azure/data-api-builder. Repo: github.com/Azure/data-api-builder. MCP overview: MCP overview on Microsoft Learn.