Learn more about Data API builder: https:\/\/aka.ms\/dab\/docs<\/a><\/p>\n<\/blockquote>\n A multi-source configuration is one of DAB’s most powerful features. There is no special requirement other than a valid connection string. This lets multiple databases take advantage of a single instance of DAB with REST and GraphQL, but also its new MCP endpoint for agentic applications.<\/p>\n Just like Data API builder’s single-source configuration, multi-source config isn’t code generation and doesn’t require writing any code. It’s a dynamic engine you control with JSON files that gives you the feature-rich API experience most development teams demand but budgets and timelines often can’t deliver. Build for developer velocity and convenience, Data API builder can deliver secure, robust endpoints by the end of lunch.<\/p>\n Working demo: https:\/\/github.com<\/a><\/p>\n<\/blockquote>\n Data API builder uses a JSON-formatted configuration file, often named There is only one DAB configuration format. Every configuration will be basically the same except for a specific connection string and entity settings. See the DAB configuration schema: https:\/\/github.com<\/a><\/p>\n<\/blockquote>\n You only give Data API builder a single configuration file. This file is the parent configuration, and it points to the child configurations with the Read Data API builder’s documentation: MS Learn<\/a><\/p>\n The parent configuration file can include entity definitions, but that is optional. What is required, however, is If a child configuration file includes a There is no limit to the number of child configuration files you can have, and there is no requirement for how many entities each one defines. You can have one child configuration with 50 entities and another with just one entity. The engine doesn’t care.<\/p>\n Multi-source config is not limited to SQL Server. You can connect to any supported database in any combination. For example, you could have one child config connecting to SQL Server and another connecting to Cosmos DB, and the API would serve them both seamlessly.<\/p>\n However, across data sources, entity names must be unique. You can’t have a Learn more about multi-source config: https:\/\/aka.ms\/dab\/docs<\/a><\/p>\n<\/blockquote>\n The demo associated to this blog post uses a retail scenario spread across three SQL Server databases. The first database has product catalog information, the second has inventory information, and the third has user-specific recommendations.<\/p>\n The API merges each data source together so the client can get a product’s details, availability, and personalized recommendation in one API surface. However, there is magic when the developer uses GraphQL, in a single request, they can get all three databases’ information merged together in one response.<\/p>\n An example of a unifying GraphQL request\/query:<\/p>\n An example of a unifying GraphQL response:<\/p>\n In addition to REST and GraphQL, the same multi-source configuration also feeds DAB’s new MCP endpoint. This means agents can access all three databases through a single surface without needing custom middleware or a custom server.<\/p>\nMulti-source configuration<\/h2>\n
![\"Multi-source](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2026\/02\/multi-config-dab.drawio.svg\")
<\/a><\/p>\n\n
\nOne config to rule them all<\/h2>\n
dab-config.json<\/code> though the name doesn’t matter, to connect to your database. In a multi-source scenario, Data API builder uses one configuration file for each database.<\/p>\n\n
data-source-files<\/code> property. The engine merges them together at runtime to create a single API surface across all databases.<\/p>\nExample use of
data-source-files<\/code>:<\/h4>\n{\n \"data-source-files\": [\n \"dab-config-catalog.json\",\n \"dab-config-inventory.json\",\n \"dab-config-recommendations.json\"\n ]\n}\n<\/code><\/pre>\nJust one runtime<\/h3>\n
runtime<\/code>. The parent configuration file’s runtime<\/code> settings are the only runtime<\/code> settings the engine obeys. This means settings like authentication<\/code>, authorization<\/code>, and caching<\/code> are global across all data sources.<\/p>\n\n
runtime<\/code> section, the engine ignores it and logs a warning. Only the parent configuration file’s runtime<\/code> section is used.<\/p>\n<\/blockquote>\nAs many as you need<\/h3>\n
Any type you need<\/h3>\n
![\"Data](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2026\/02\/dab-supported-databases.svg\")
<\/a><\/p>\nImportant limits<\/h3>\n
products<\/code> entity in two different child configuration files. If you do, the engine throws an error at startup and doesn’t run. This is also true with GraphQL type names and REST paths. For a single DAB instance to serve multiple databases, it needs a single unified namespace.<\/p>\n\n
\nTry it out<\/h2>\n
CatalogDb \u2192 Products and Pricing\nInventoryDb \u2192 Inventory and Warehouse\nRecommendationsDb \u2192 Recommendations and Ratings\n<\/code><\/pre>\nGraphQL special behavior<\/h3>\n
{\n products { items { ProductId Name Category Price } }\n inventories { items { ProductId StockCount Warehouse } }\n recommendations { items { UserId ProductId Score } }\n}\n<\/code><\/pre>\n{\n \"data\": {\n \"products\": {\n \"items\": [\n { \"ProductId\": 1, \"Name\": \"Widget\", \"Category\": \"Gadgets\", \"Price\": 19.99 },\n { \"ProductId\": 2, \"Name\": \"Gizmo\", \"Category\": \"Gadgets\", \"Price\": 29.99 }\n ]\n },\n \"inventories\": {\n \"items\": [\n { \"ProductId\": 1, \"StockCount\": 100, \"Warehouse\": \"A\" },\n { \"ProductId\": 2, \"StockCount\": 50, \"Warehouse\": \"B\" }\n ]\n },\n \"recommendations\": {\n \"items\": [\n { \"UserId\": 123, \"ProductId\": 1, \"Score\": 4.5 },\n { \"UserId\": 123, \"ProductId\": 2, \"Score\": 3.8 }\n ]\n }\n }\n}\n<\/code><\/pre>\nAgentic applications<\/h3>\n
\n
![\"Aspire](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2026\/02\/aspire-demo.webp\")
<\/a><\/p>\n