Building an app against Azure SQL has always involved a small scavenger hunt: which service tier fits your workload, which connection library your language wants, which quickstart actually applies. Microsoft’s new Azure SQL Dev Hub, announced in public preview, tries to collapse that hunt into a single starting point in the Azure portal. Per the announcement, it targets two audiences at once: developers who connect directly, and AI agents that build against the database on their behalf.
The preview ships with connection guidance for .NET, Python, Node.js and Java, along with pointers to the resources you need to go from an empty subscription to a working connection. That sounds mundane, and for a human it mostly is. For an AI agent it matters more: an agent following documented, canonical steps makes fewer creative mistakes than one assembling the same procedure from blog posts it half remembers.
Choosing an Azure SQL service is genuinely hard
The hub exists because the Azure SQL family is not one product. Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure Virtual Machines, and SQL database in Microsoft Fabric all overlap in surface area but differ in migration effort, feature coverage and billing. Picking wrong is expensive to walk back, and the differences are exactly the kind of detail that only shows up after you have provisioned something.
The hub’s answer is a recommendation flow: answer a few questions, or chat with Azure portal Copilot to refine requirements, then get a suggested service with a side-by-side comparison before you commit. For existing users Microsoft says nothing changes except a streamlined navigation pane, so the hub is mostly a new-user onramp rather than a disruption. There is also a path that takes you straight to the resource creation page with a free offer pre-applied, which is a nice touch for prototypes.
The agent story is the more interesting part
Dev Hub lands in the middle of a broader push to make Azure SQL legible to AI agents. Microsoft Learn’s intelligent applications guidance describes the SQL MCP Server, which sits directly in the data path for agents: instead of exposing raw schema or trusting whatever SQL a model generates, it routes access through a defined set of tools backed by your configuration. Agents discover available capabilities and operate without guessing at schema, which reduces errors and removes the prompt engineering normally needed to compensate for ambiguity. The same configuration that governs REST and GraphQL access also governs MCP, so the rules are not duplicated.
Alongside that, Microsoft maintains an agent skills collection for running the real Azure SQL Database engine locally in a container. The skills cover provisioning, schema migration, RAG against the engine’s native VECTOR type, CI runs, sidecar deployments, and even building a prefilled GitHub issue for filing bugs. They follow the skills.sh convention and work in Claude Code, Codex, Cursor and VS Code with GitHub Copilot. The container runs the same engine the cloud service runs, so the T-SQL dialect, system views and driver behavior match what production will do, and a project developed against the local engine moves to the managed service as a connection-string change rather than a porting exercise.
Read together, the direction is clear. Microsoft is positioning Azure SQL as the database that agent-driven tools already know how to drive. The Dev Hub is the human-facing entry point to that story; the MCP server and the skills collection are the machine-facing ones. Teams evaluating agent-built data apps now have a documented path from “agent, provision me a database” to “agent, write the RAG pipeline” that does not require a human to hand-hold every step.
Where it fits with the rest of the tooling
The hub does not replace existing paths. The MSSQL extension for VS Code already offers guided Azure SQL Database provisioning in public preview, including the free tier, with the connection added to your editor the moment provisioning finishes. That extension also carries Schema Designer with GitHub Copilot, Data API builder integration and SQL Notebooks, so the editor path has been getting richer on its own schedule. Data API builder can turn a database into REST and GraphQL endpoints without backend code. What the hub adds on top is discovery: one place to compare services, get a recommendation, and land on the right creation page without leaving the portal.
One honest limitation: a recommendation wizard is only as good as its questions, and workload sizing rarely fits multiple choice. If your team already knows it wants Managed Instance for lift-and-shift compatibility, the hub will not tell you anything new, and that is fine. The value is for the developer who opens the portal once a quarter and cannot remember which database product they are supposed to click, and for the growing number of agents who need the same answer in a form they can consume.
Preview caveats, then a suggestion
Preview features carry supplemental terms and can change or disappear before general availability, so do not wire anything load-bearing to the hub yet. For new projects, or for teams that regularly onboard developers to Azure SQL, it is worth ten minutes: search for “azure sql” in the portal, walk through the recommendation flow, and check whether the suggested path matches what your team actually does. If it does, the hub quietly removes the scavenger hunt for every new person who joins, and the agent-facing tooling around it is where the longer-term payoff sits.