Data API Builder: Automatic REST, GraphQL, and MCP Endpoints for Azure Databases

The Problem DAB Solves and Who It Is For

Writing REST or GraphQL endpoints for database tables is repetitive work: declare the schema, map each field, implement CRUD operations, handle pagination, wire up authentication. Data API builder (DAB) automates this pipeline. You point it at a database, declare which tables or views to expose, set permissions, and DAB generates the endpoints without any hand-written endpoint code.

The project targets backend developers working with Azure databases who want to accelerate API development, and frontend teams who need a data layer without waiting for a custom backend. The README positions it as a CRUD data API engine that runs in a container on Azure, any other cloud, or on-premises. DAB is open-source and always free under the MIT License, according to the README.

How DAB Translates Requests to SQL

DAB reads a JSON configuration file on startup, queries the database for schema metadata, and starts an HTTP engine. When a request arrives, DAB authorises it against the permissions defined in the configuration, passes the request to a query builder, which constructs the SQL statement, executes it against the database, and returns JSON.

The same translation applies to GraphQL: the GraphQL schema is derived from the configuration, and each query resolves to a SQL statement. For MCP (Model Context Protocol) endpoints, DAB exposes the same data to AI agent clients using the MCP protocol, allowing large language model tools to query the database through conversation without custom connector code.

DAB supports tables, views, and stored procedures. Views are declared with `type: view` in the entity configuration; stored procedures with `type: stored-procedure`. When the type is not specified, DAB defaults to `table`.

Installing DAB and Setting Up a First Endpoint

DAB runs on the .NET runtime version 8 or later. Install it as a global .NET tool:

dotnet tool install microsoft.dataapibuilder -g

Verify the installation:

dab --version

DAB reads connection strings from environment variables referenced in the configuration file. On macOS or Linux, store the connection string in a `.env` file:

echo "my-connection-string=$database_connection_string" > .env

Initialise the configuration file for an MS SQL database in development mode:

dab init --database-type mssql --connection-string "@env('my-connection-string')" --host-mode development

This creates `dab-config.json` in the current folder. Development mode enables the Swagger UI for REST and the Nitro UI for GraphQL. Add a table named `Todo` from the `dbo` schema:

dab add Todo --source "dbo.Todo" --permissions "anonymous:*"

Start the engine:

dab start

DAB looks for `dab-config.json` in the local folder by default. The REST endpoint is then available at `http://localhost:5000/api/Todo` and the health check at `http://localhost:5000/health`. The Swagger UI is at `http://localhost:5000/swagger` and the GraphQL playground at `http://localhost:5000/graphql`.

Container Deployment and the Dockerfile

In production, DAB runs in a container. The included Dockerfile builds from `mcr.microsoft.com/dotnet/sdk:10.0-azurelinux3.0`, compiles the service, and uses `mcr.microsoft.com/dotnet/aspnet:10.0-azurelinux3.0` as the runtime base. The container exposes port 5000 via the `ASPNETCORE_URLS=http://+:5000` environment variable and uses `dotnet Azure.DataApiBuilder.Service.dll` as the entrypoint.

A non-root variant of the Dockerfile is available as the `runtime-nonroot` stage. It runs under UID 1654 (the numeric user shipped with the azurelinux3.0 base image) rather than root. The README notes this variant is friendlier to image scanners and Kubernetes `runAsNonRoot` checks. Build it with `docker build --target runtime-nonroot`.

The `.env` file pattern used in development should not be committed to source control; the README explicitly recommends adding `.env` to `.gitignore`. In container deployments, connection strings should be passed as environment variables through the container orchestration platform rather than baked into the image.

Permission Model and Authentication

Every entity in the DAB configuration requires at least one permission entry. The permissions block in `dab-config.json` associates a role name with the actions it may perform. The `anonymous` role covers unauthenticated requests; named roles cover authenticated users. Actions can be `*` for all CRUD operations or individual verbs for finer control.

DAB supports authentication but the README does not detail the full authentication mechanism in the repository-level documentation; the full guide is in the Azure documentation at `https://aka.ms/dab/docs`. The `--host-mode development` flag is specifically a local tooling mode; the README marks this with an explicit note that it enables Swagger and Nitro, which should not be exposed in production without appropriate access controls.

Limitations and When DAB Is the Wrong Choice

DAB generates endpoints directly from the database schema, which means business logic that lives outside of SQL stored procedures must be implemented elsewhere. If your API needs to call external services, run complex validation, or apply transformations that cannot be expressed in SQL, DAB is not the right layer for that logic. You would need a separate service in front of or behind DAB.

The tool is tightly coupled to the Microsoft and Azure database ecosystem. The database support matrix covers Azure SQL, SQL Server, SQL Data Warehouse, Cosmos DB, PostgreSQL, and MySQL. Other databases, including Oracle, MongoDB, and SQLite-adjacent systems outside what is listed, are not supported. Teams building on a non-listed database have no migration path.

DAB requires .NET 8 or later. Python, Node.js, or Go stacks that do not already run a .NET runtime will need to add one, which adds infrastructure complexity. The CLI also assumes that `dab-config.json` is in the local folder; the README notes this explicitly and the tool will not start if that file is absent or misnamed.

Configuration is managed entirely through `dab-config.json`. There is no built-in migration tool for schema changes: when the underlying database schema changes, the configuration file must be updated to match. Teams with frequent schema changes will need to maintain that synchronisation manually or script it.

Comparison with PostgREST and Hasura

PostgREST is a similar no-code REST API generator, but it is PostgreSQL-only and does not support GraphQL or MCP. DAB covers more database types and protocol options, but PostgREST has been in production use longer and has a larger operator community for PostgreSQL-specific deployments.

Hasura generates GraphQL APIs automatically from PostgreSQL and MS SQL schemas and also runs in a container. Its core is open-source but some features require a paid plan. DAB covers REST and MCP in addition to GraphQL, and the entire feature set is free. The trade-off is that Hasura has a more mature query engine for complex GraphQL use cases, while DAB is the natural choice for teams already invested in the Azure toolchain.

Editorial conclusion

Data API builder is the right tool for .NET and Azure-centric teams that need database APIs quickly without writing boilerplate CRUD code. It is a poor fit for polyglot stacks, databases outside its support matrix, or projects that need complex business logic inside the API layer. Verify which database version you are targeting against the current support table in the documentation before starting a production integration, as driver support varies by engine.

Frequently asked questions

Official sources

1. Azure/data-api-builder on GitHub
2. License: MIT
3. Project website
4. README
5. Releases