DAB 2.0 Preview: Autoconfiguration with autoentities

If you've been maintaining a large dab-config.json, you know the pain: every table, view, and stored procedure needs its own entities block. Schema grows, config grows. Someone adds a table and forgets to update the config, and suddenly your API is silently missing endpoints.

DAB 2.0 Preview introduces autoentities — a pattern-based approach that discovers and exposes database objects automatically, every time DAB starts. This post covers how it works, how to configure it from the CLI, and what to watch for.

Getting started

As DAB 2.0 is still in preview, you first need to install the preview version:

dotnet tool install microsoft.dataapibuilder --prerelease

Note: MSSQL data sources only, for now.

Initialize a new dab-config.json file if it doesn't exists yet:

dotnet dab init

Remark: Notice that we prefix dab with dotnet to avoid collisions with the globally installed release version.

How it works

Instead of defining each entity explicitly, you define one or more named definitions under autoentities. Each definition combines:

• patterns — which database objects to include/exclude and how to name them
• template — which endpoints (REST, GraphQL, MCP) to enable and caching settings
• permissions — role-based access control applied to all matched entities

DAB evaluates these patterns at startup using T-SQL LIKE syntax against schema.object identifiers. Any new tables matching your patterns are automatically picked up — no config changes needed.

Here's a minimal but complete example:

This exposes every table in dbo (except those starting with internal or __migration), names them as dbo_TableName, enables REST and GraphQL, caches responses for 30 seconds, and grants anonymous read access.

Patterns

Include and exclude

The include array uses % as a wildcard, matched against schema.object:

Pattern
Matches

%.%
Everything (default)

dbo.%
All objects in dbo

dbo.Product%
Objects prefixed with Product in dbo

%.%_staging
Staging tables across all schemas

dbo.Products
Exactly dbo.Products (no wildcard)

exclude is evaluated after include, so it removes objects from the matched set. Always include the schema name when targeting specific tables:

"patterns": {
  "include": [ "dbo.%", "sales.%" ],
  "exclude": [ "dbo.internal%", "%.vw_%", "dbo.sysdiagrams" ]
}

Entity naming

The name property is a string template using {schema} and {object} placeholders. It defaults to {object} — just the object name — but when you're matching across multiple schemas, {schema}_{object} avoids name collisions:

Template
dbo.Products becomes

{object}
Products

{schema}_{object}
dbo_Products

api_{object}
api_Products

{schema}_{object}_v1
dbo_Products_v1

Using the CLI

Instead of hand-editing JSON, use dab auto-config to write or update autoentities definitions directly into your config file.

Basic usage

dotnet dab auto-config public-api \
  --patterns.include "dbo.%" \
  --patterns.exclude "dbo.internal%" \
  --patterns.name "{schema}_{object}" \
  --permissions "anonymous:read"

This writes the following into dab-config.json:

Multiple include patterns

Space-separate multiple values in the CLI:

dotnet dab auto-config reporting \
  --patterns.include "dbo.Products" "dbo.Orders" "dbo.Customers" \
  --permissions "authenticated:read"

Enabling specific endpoints:

dotnet dab auto-config public-api \
  --patterns.include "dbo.%" \
  --template.rest.enabled true \
  --template.graphql.enabled false \
  --template.mcp.dml-tools false \
  --permissions "anonymous:read"

With caching:

dab auto-config public-api \
  --patterns.include "dbo.%" \
  --template.cache.enabled true \
  --template.cache.ttl-seconds 60 \
  --template.cache.level L1L2 \
  --permissions "anonymous:read"

Cache levels: L1 (in-process memory) or L1L2 (in-process + Redis).

Preview matches before committing

Before your patterns are persisted to config, you can dry-run them with dab auto-config-simulate. It connects to your database, resolves the patterns, and prints what would be exposed — without writing any changes:

dab auto-config-simulate --config ./dab-config.json

Console output:

For CI/CD pipelines, export to CSV with --output:

dab auto-config-simulate \
  --config ./dab-config.json \
  --output results.csv

CSV output:

filter_name,entity_name,database_object
public-api,dbo_Products,dbo.Products
public-api,dbo_Inventory,dbo.Inventory
public-api,dbo_Pricing,dbo.Pricing

This is useful for asserting expected entity counts in a pipeline, or reviewing what a schema change would expose before deploying.

Mixing autoentities with entities

You don't have to replace your existing entities config wholesale. Both sections can coexist:

When both sections define an entity with the same name, the explicit entities definition wins. This lets you use autoentities as a baseline and override only the entities that need custom relationships, REST paths, or tighter permissions.

Full example: Multiple definitions

Multiple autoentities definitions let you apply different templates and permissions to different parts of your schema:

Here, public-read exposes most of dbo as read-only with caching, while admin-full exposes everything, including audit tables, as Admin_TableName with full CRUD for admins only.

What to watch for

• Preview only. This feature is in preview and may change before GA. Don't use it in production yet.
• MSSQL only. No support for PostgreSQL, MySQL, or CosmosDB yet.
• Startup re-evaluation. autoentities is applied at every startup. If a table matching your include pattern is dropped, it simply won't appear. If one is added, it shows up automatically — which is the feature, but worth being aware of in environments where schema changes are uncontrolled.
• Name collisions. If two definitions produce entities with the same name, the behaviour may be undefined. Use {schema}_{object} or unique name templates when targeting overlapping schemas.

More information

What's new for version 2.0 - Preview - Data API builder | Microsoft Learn