Azure SQL | The .NET Blog

NL2SQL Is the SQL Injection of the Agentic Age

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

There’s a version of the NL2SQL pitch that sounds perfect: users ask questions in natural language, agents generate SQL, data comes back. Fewer screens, fewer queries, less code. Simple.

Then you think about it for five more minutes.

The Problems Nobody Talks About in the Demo

Schemas weren’t designed to explain things. Cryptic table names, inconsistent column names, technically valid relationships that are semantically invalid without additional predicates — these are normal for enterprise databases. They’re not bugs, they’re just the accumulated history of business changes. But when you ask a model to infer intent from a schema that wasn’t designed to communicate intent, the model will try anyway. It won’t give up. It’ll generate its best-effort query and return results with confidence.

Models are not deterministic. Ask the same question about the same database twice and you might get different SQL. The model is calculating probabilities, and slight variations in context drive different outputs. You cannot test your way to a guarantee that the agent always generates the right query.

User review doesn’t scale. “Just review every query before execution” sounds safe. But it assumes users are experts in both the data model and SQL — exactly the people who didn’t need the natural language interface. It also introduces cognitive overload and a new class of confirmation bias, where users overwhelmed by query complexity approve invalid queries rather than investigate them.

And then there’s injection. In traditional SQL development, parameterization solved injection because user input filled parameters, not SQL structure. With NL2SQL, the model is generating the SQL itself. The prompt, schema context, conversation history, and retrieved data all influence what gets executed. If someone crafts a prompt that changes what the model generates, that’s injection — not at the parameter level, but at the query generation level. And unlike dropping a table (obvious, recoverable), NL2SQL injection produces queries that return incorrect results with no visible error. Business decisions get made on wrong data.

What SQL MCP Server Actually Solves

This is where the article makes its most useful practical point. Instead of giving an agent arbitrary schema access and hoping for the best, SQL MCP Server exposes a curated API surface built on top of Data API builder.

The difference matters: the agent doesn’t generate SQL. It calls named endpoints that return predefined result shapes. The SQL is written once, by a developer, and is deterministic. The agent’s nondeterminism is limited to choosing which endpoint to call, not constructing arbitrary queries.

This is analogous to what parameterization did for SQL injection in the traditional app model — you remove the ability to construct arbitrary queries from untrusted input.

The Right Question

The article doesn’t say “never use NL2SQL.” It says: be deliberate about where you apply it and what you expose. For exploratory analysis in a controlled environment, with a scoped schema and read-only access, NL2SQL might be fine. For production systems where business decisions depend on the results, a curated API layer is significantly safer.

Honesty: some problems are genuinely better solved with structured queries behind named endpoints than with natural language to SQL. SQL MCP Server gives you that option without abandoning the agentic interface entirely.

Original post: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL Can Generate Embeddings Now — In Pure T-SQL, No App Layer Needed

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

If you’ve ever built a RAG pipeline, you know the pipeline tax: your data lives in SQL, but to generate embeddings you need to extract it, call an embedding API, handle batching and rate limits, and store the results somewhere vector-searchable. Often in a different database entirely.

Azure SQL just removed most of that with two features that are now generally available: CREATE EXTERNAL MODEL and AI_GENERATE_EMBEDDINGS.

What They Do

These two T-SQL features work as an integrated pipeline:

CREATE EXTERNAL MODEL — registers an external AI model endpoint as a named database object. You set the location, API format, model type, and credentials once. Reuse it everywhere.

AI_GENERATE_EMBEDDINGS — a scalar T-SQL function that calls the registered model and returns a JSON array of vector values. Works in SELECT, INSERT, UPDATE, and MERGE statements.

Together they form an end-to-end embedding pipeline without leaving the SQL engine.

The Complete Workflow

-- Step 1: Register your embedding provider once
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Step 2: Generate embeddings inline in T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Step 3: Search with vector distance
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

That’s the whole pipeline: data in SQL, embeddings generated in SQL, similarity search in SQL. No orchestration layer, no ETL, no separate vector database.

Supported API Formats and Options

At GA, API_FORMAT supports Azure OpenAI and OpenAI. MODEL_TYPE is locked to EMBEDDINGS for now. The PARAMETERS JSON lets you set model-level defaults including retry count:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

Authentication uses database credentials, so secrets stay out of your application code.

What This Enables for .NET Applications

For .NET developers building AI features on top of existing SQL data, this is significant. You don’t need to:

Extract data to an intermediate store for embedding
Manage an external embedding pipeline
Set up a separate vector database (though you can use Azure AI Search if you want a full-featured vector store)
Change your application’s data access layer

You can add semantic search to existing SQL applications incrementally, using the same T-SQL tooling you already have.

Wrapping Up

RAG patterns on SQL data just got dramatically simpler. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL means your existing SQL application can gain vector search capabilities without adding new infrastructure.

Both features are GA in Azure SQL Database and Azure SQL Managed Instance today.

Original post: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio Is Retired: Move Your Azure SQL Workflow to VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

Azure Data Studio retired on February 6, 2025, with support ending February 28, 2026 — the recommended replacement is VS Code with the MSSQL extension.

What to install

Three things to get started:

MSSQL extension — search “SQL Server (mssql)” in the VS Code Marketplace
SQL Database Projects extension — schema-as-code, build validation, guided publish
.NET 8 SDK — required by the build system; missing SDK is the most common first-run issue

Migrating your ADS connections and settings

The MSSQL extension ships an ADS Migration Toolkit that handles the one-time migration in a guided flow: saved connections, connection groups, settings, and key bindings are all imported automatically.

Restoring F5 muscle memory

ADS users rely on F5 to run queries. Install the MSSQL Database Management Keymap extension to get ADS-style key bindings back, including F5.

SQL Database Projects: schema as code

Right-click a project → Publish → configure target → review the generated T-SQL script → deploy. The script preview before deployment is the key safety feature. Item templates generate stubs for tables, stored procedures, and views — the same workflow as SSDT.

Common gotcha: a target platform mismatch in the .sqlproj file will cause build errors if the project was created against a different SQL Server version.

Schema Compare and Schema Designer

The extension also includes Schema Compare (diff your project against the deployed database) and Schema Designer (visual schema editing without writing DDL by hand).

Microsoft Fabric developers

The setup is identical, but start from the Fabric portal and connect the database to Git first before opening it in VS Code. Microsoft has a dedicated guide: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Wrapping up

The migration is a one-time guided flow, not a manual rebuild. Install the three tools, run the ADS Migration Toolkit, restore your key bindings, and you’re back to normal in under 10 minutes.

See the full article for step-by-step screenshots and the Fabric-specific walkthrough.

SQL MCP Server on Azure App Service — No Containers Required

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Let me be honest with you: every time I see “requires a container” in a tutorial, a little part of me sighs. Containers are great — until your team doesn’t have a container strategy, and suddenly a feature that looked simple is blocked behind orchestration overhead you didn’t plan for.

That’s why this one caught my eye. The SQL MCP Server can now run on Azure App Service — no Docker, no Kubernetes, just the same Data API builder (DAB) configuration that exposes your SQL database through MCP, REST, and GraphQL.

What’s SQL MCP Server, Again?

Quick context if you haven’t run into it yet. SQL MCP Server sits between your AI agent and your SQL database. Instead of giving your agent direct database access (which is a terrible idea), it exposes your tables and views as an abstraction layer — entities with defined permissions.

It’s built on top of Data API builder, which means one configuration file drives MCP and REST and GraphQL simultaneously. Your agent talks to the MCP endpoint. Your traditional app talks to REST or GraphQL. Same config, same runtime, different surfaces.

That’s genuinely useful. You’re not maintaining two separate API layers.

The Container Problem (and the Solution)

The original deployment model for SQL MCP Server was containers. That works well in many shops — but not all. Plenty of .NET teams standardize on Azure App Service or VMs. Requiring a container runtime just to expose a SQL endpoint adds friction nobody asked for.

The new walkthrough shows you how to skip the container entirely. The whole thing runs with a dab start command, hosted on App Service as a standard .NET 8 web process.

Here’s the local setup flow in a nutshell:

# Install Data API builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Initialize the configuration
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Add an entity
dab add products --source dbo.products --permissions "authenticated:*"

# Configure App Service auth provider
dab configure --runtime.host.authentication.provider AppService

# Start the server
dab start

At this point you have MCP at /mcp, REST and GraphQL from the same process, and nothing running in a container.

Authentication That Doesn’t Involve Shared API Keys

This is the part I appreciate most. When you deploy to App Service, you configure Microsoft Entra ID as the authentication provider. No shared secrets embedded in config files, no API keys to rotate.

The connection string stays in an App Service environment variable (not in dab-config.json), and the MCP endpoint is protected by platform authentication. If you’re already aligned to Entra ID across your Azure workloads — which you probably are if you’re using Azure AI Foundry agents — this fits naturally.

For local development, you switch to Simulator mode and STDIO transport. Flip back to AppService mode when deploying. Clean and explicit.

Deploying to App Service

The actual deployment is straightforward Azure CLI work:

# Create the App Service plan
az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

# Create the web app (.NET 8 runtime)
az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

# Set the startup command
az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Then deploy your DAB project using whatever code deployment path your team already uses — VS Code, GitHub Actions, Zip Deploy. The key detail: it’s a code deployment, not a container deployment. No image to build, push, or manage.

Why This Matters for .NET Developers

If you’re building AI agents in .NET — whether with the Microsoft Agent Framework, Semantic Kernel, or Azure AI Foundry hosted agents — eventually your agent needs to talk to a database. SQL MCP Server gives you a structured way to do that without exposing raw connection strings or writing a custom API layer.

Running it on App Service closes the gap for teams that aren’t running containers. It’s the same DAB config, the same Entra auth, the same MCP protocol — just on infrastructure you already know.

Check out the full walkthrough in the original blog post and the sample repo on GitHub.

Wrapping Up

The SQL MCP Server on App Service is a solid pragmatic option for .NET teams that want to give their agents structured access to SQL data without a container strategy. The combination of DAB’s entity model, App Service’s built-in Entra auth, and the dab start startup command makes for a deployment that’s simple to explain and easy to operate.

Give it a try. Your agents will appreciate the clean API surface. Your ops team will appreciate not having to deal with container registries.

SQL Server 2025 as Your Agent-Ready Database: Security, Backup, and MCP in One Engine

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

I’ve been following the Polyglot Tax series by Aditya Badramraju with a lot of interest. Parts 1-3 built a compelling case for SQL Server 2025 as a genuinely multi-model database — JSON, graph, vectors, and relational data all in one engine with a unified query planner. Part 4 closes the series with the parts that actually determine whether you’d trust this architecture in production.

Spoiler: the production story is solid.

One Security Model to Rule All Data Models

Here’s the thing with polyglot stacks: when an auditor asks “prove that Tenant A cannot see Tenant B’s data,” you have to answer that question for each database independently. Five databases, five security models, five proofs.

With SQL Server 2025, you define one Row-Level Security policy and it covers every data model:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

From that point, every query — relational joins, JSON path queries, graph traversals, vector similarity searches — is automatically filtered by tenant. The engine injects the predicate into the execution plan before any data leaves storage. Your calling code doesn’t need WHERE TenantID = @id everywhere. You test the policy once.

The layers compose further: Dynamic Data Masking for columns that shouldn’t show full values to certain roles, Always Encrypted for end-to-end encryption (even DBAs can’t read it), and stored procedures as the permission boundary so agents only call what you explicitly exposed.

This is the part of the architecture that matters most for compliance-heavy SaaS. One policy, one proof.

Unified Backup = Atomic Recovery

One statement, all data models, consistent point in time:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

In a polyglot stack, point-in-time recovery across five databases means coordinating five restore operations and hoping the timestamps line up within a second or two. For financial data, that two-second inconsistency is unacceptable. With one database, one transaction log, one restore — recovery is atomic by definition.

Ledger Tables for Tamper-Evident Audit Trails

For regulated industries, you need more than “we have logs.” You need cryptographic proof that those logs weren’t modified:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

Every insert, update, and delete gets cryptographically hashed into a blockchain-style structure. You can prove to an auditor — mathematically — that a row hasn’t been tampered with since it was written. In a polyglot stack, this capability doesn’t exist uniformly across all your databases.

MCP Integration: Agents Without Hand-Coded Middleware

The series built toward this: SQL Server 2025 supports the SQL MCP Server directly, which means your agents can call the database through natural language tool calls without you writing middleware for every operation.

Combine that with stored procedures as the permission boundary and Row-Level Security enforced at the engine, and you have a model where:

Agent calls a tool (e.g., “get customer context for account 12345”)
MCP translates to the stored procedure you defined
SQL engine enforces tenant isolation and column masking automatically
Agent gets exactly the data it’s allowed to see

No middleware layer. No ad-hoc query injection risk. The engine handles authorization, not the agent.

Why This Matters for .NET Developers

If you’re building .NET services with SQL Server as your primary store, the message from this series is: you don’t need to add Redis for caching, a graph DB for relationships, or a vector store for embeddings. SQL Server 2025 handles all of that — with better operational consistency than a polyglot stack and unified security that’s actually auditable.

The MCP integration means your Semantic Kernel agents or Microsoft Agent Framework workflows can interact with your data tier through the same SQL MCP Server, with the same security guarantees you’d enforce for human queries.

Wrapping up

The Polyglot Tax series is worth reading end-to-end. Parts 1-3 prove the query planner story. Part 4 proves the production story. For .NET developers building agent-first or AI-augmented applications on Azure SQL, this architecture deserves serious consideration.

Original post by Aditya Badramraju: The Polyglot Tax – Part 4.

SQL MCP Server — The Right Way to Give AI Agents Database Access

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Let’s be honest: most database MCP servers available today are terrifying. They take a natural language query, generate SQL on the fly, and run it against your production data. What could go wrong? (Everything. Everything could go wrong.)

The Azure SQL team just introduced SQL MCP Server, and it takes a fundamentally different approach. Built as a feature of Data API builder (DAB) 2.0, it gives AI agents structured, deterministic access to database operations — without NL2SQL, without exposing your schema, and with full RBAC at every step.

Why no NL2SQL?

This is the most interesting design decision. Models aren’t deterministic, and complex queries are the most likely to produce subtle errors. The exact queries users hope AI can generate are also the ones that need the most scrutiny when produced non-deterministically.

Instead, SQL MCP Server uses an NL2DAB approach. The agent works with Data API builder’s entity abstraction layer and built-in query builder to produce accurate, well-formed T-SQL deterministically. Same result for the user, but without the risk of hallucinated JOINs or accidental data exposure.

Seven tools, not seven hundred

SQL MCP Server exposes exactly seven DML tools, regardless of database size:

describe_entities — discover available entities and operations
create_record — insert rows
read_records — query tables and views
update_record — modify rows
delete_record — remove rows
execute_entity — run stored procedures
aggregate_records — aggregation queries

This is smart because context windows are the agent’s thinking space. Flooding them with hundreds of tool definitions leaves less room for reasoning. Seven fixed tools keep the agent focused on thinking rather than navigating.

Each tool can be individually enabled or disabled:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Getting started in three commands

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

That’s a running SQL MCP Server exposing your Customers table. The entity abstraction layer means you can alias names and columns, limit fields per role, and control exactly what agents see — without exposing internal schema details.

The security story is solid

This is where Data API builder’s maturity pays off:

RBAC at every layer — each entity defines which roles can read, create, update, or delete, and which fields are visible
Azure Key Vault integration — connection strings and secrets managed securely
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — agents interact through a controlled contract, not raw SQL

The schema abstraction is particularly important. Your internal table and column names never get exposed to the agent. You define entities, aliases, and descriptions that make sense for the AI interaction — not your database ERD.

Multi-database and multi-protocol

SQL MCP Server supports Microsoft SQL, PostgreSQL, Azure Cosmos DB, and MySQL. And because it’s a DAB feature, you get REST, GraphQL, and MCP endpoints simultaneously from the same configuration. Same entity definitions, same RBAC rules, same security — across all three protocols.

Auto-configuration in DAB 2.0 can even inspect your database and build the configuration dynamically, if you’re comfortable with less abstraction for rapid prototyping.

My take

This is how enterprise database access for AI agents should work. Not “hey LLM, write me some SQL and YOLO it against production.” Instead: a well-defined entity layer, deterministic query generation, RBAC at every step, caching, monitoring, and telemetry. It’s boring in the best possible way.

For .NET developers, the integration story is clean — DAB is a .NET tool, the MCP Server runs as a container, and it works with Azure SQL, which most of us are already using. If you’re building AI agents that need data access, start here.

Wrapping up

SQL MCP Server is free, open-source, and runs anywhere. It’s the prescriptive approach from Microsoft for giving AI agents secure database access. Check out the full post and the documentation to get started.