Azure SQL | The .NET Blog

NL2SQL é a Injeção SQL da Era Agêntica

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

Há uma versão do argumento NL2SQL que soa perfeita: os usuários fazem perguntas em linguagem natural, os agentes geram SQL, os dados voltam. Menos telas, menos consultas, menos código. Simples.

Então você pensa por mais cinco minutos.

Os Problemas sobre os quais Ninguém Fala na Demo

Os esquemas não foram projetados para explicar as coisas. Nomes de tabelas crípticos, nomes de colunas inconsistentes, relacionamentos tecnicamente válidos que são semanticamente inválidos sem predicados adicionais — isso é normal para bancos de dados empresariais. Não são bugs, são simplesmente a história acumulada das mudanças de negócio. Mas quando você pede a um modelo que infira intenção de um esquema que não foi projetado para comunicar intenção, o modelo tentará de qualquer forma. Não desistirá. Gerará sua melhor consulta possível e retornará resultados com confiança.

Os modelos não são determinísticos. Faça a mesma pergunta sobre o mesmo banco de dados duas vezes e você pode obter SQL diferente. O modelo está calculando probabilidades, e ligeiras variações no contexto geram saídas diferentes. Você não pode testar seu caminho para uma garantia de que o agente sempre gera a consulta correta.

A revisão do usuário não escala. “Apenas revise cada consulta antes da execução” soa seguro. Mas assume que os usuários são especialistas tanto no modelo de dados quanto em SQL — exatamente as pessoas que não precisavam da interface de linguagem natural. Também introduz sobrecarga cognitiva e uma nova classe de viés de confirmação, onde usuários sobrecarregados pela complexidade da consulta aprovam consultas inválidas em vez de investigá-las.

E então há injeção. No desenvolvimento SQL tradicional, a parametrização resolveu a injeção porque a entrada do usuário preenchia parâmetros, não a estrutura SQL. Com NL2SQL, o modelo gera o SQL em si. O prompt, o contexto do esquema, o histórico de conversação e os dados recuperados influenciam o que é executado. Se alguém elabora um prompt que muda o que o modelo gera, isso é injeção — não no nível do parâmetro, mas no nível de geração de consultas. E ao contrário de eliminar uma tabela (óbvio, recuperável), a injeção NL2SQL produz consultas que retornam resultados incorretos sem nenhum erro visível. Decisões de negócio são tomadas com dados errados.

O que o SQL MCP Server Realmente Resolve

É aqui que o artigo faz seu ponto prático mais útil. Em vez de dar a um agente acesso arbitrário ao esquema e esperar o melhor, o SQL MCP Server expõe uma superfície de API curada construída sobre o Data API builder.

A diferença importa: o agente não gera SQL. Ele chama endpoints nomeados que retornam formas de resultado predefinidas. O SQL é escrito uma vez, por um desenvolvedor, e é determinístico. O não-determinismo do agente é limitado a escolher qual endpoint chamar, não a construir consultas arbitrárias.

Isso é análogo ao que a parametrização fez para a injeção SQL no modelo de aplicativo tradicional — você remove a capacidade de construir consultas arbitrárias a partir de entrada não confiável.

A Pergunta Certa

O artigo não diz “nunca use NL2SQL.” Ele diz: seja deliberado sobre onde você o aplica e o que você expõe. Para análise exploratória em um ambiente controlado, com um esquema limitado e acesso somente leitura, NL2SQL pode estar bem. Para sistemas de produção onde decisões de negócio dependem dos resultados, uma camada de API curada é significativamente mais segura.

Honestidade: alguns problemas são genuinamente melhor resolvidos com consultas estruturadas atrás de endpoints nomeados do que com linguagem natural para SQL. O SQL MCP Server te dá essa opção sem abandonar completamente a interface agêntica.

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

Azure SQL Agora Pode Gerar Embeddings — Em T-SQL Puro, Sem Camada de Aplicação

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

Se você já construiu uma pipeline RAG, conhece o imposto da pipeline: seus dados vivem no SQL, mas para gerar embeddings você precisa extraí-los, chamar uma API de embeddings, lidar com batching e limites de taxa, e armazenar os resultados em algum lugar com busca vetorial. Muitas vezes em um banco de dados completamente diferente.

O Azure SQL acabou de eliminar a maior parte disso com duas funcionalidades que agora estão geralmente disponíveis: CREATE EXTERNAL MODEL e AI_GENERATE_EMBEDDINGS.

O Que Elas Fazem

Essas duas funcionalidades T-SQL funcionam como uma pipeline integrada:

CREATE EXTERNAL MODEL — registra um endpoint de modelo de IA externo como um objeto de banco de dados nomeado. Você define a localização, o formato da API, o tipo de modelo e as credenciais uma vez. Reutilize em qualquer lugar.

AI_GENERATE_EMBEDDINGS — uma função T-SQL escalar que chama o modelo registrado e retorna um array JSON de valores vetoriais. Funciona em instruções SELECT, INSERT, UPDATE e MERGE.

Juntos formam uma pipeline de embeddings de ponta a ponta sem sair do motor SQL.

O Fluxo de Trabalho Completo

-- Passo 1: Registre seu provedor de embeddings uma vez
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'
);

-- Passo 2: Gere embeddings inline em T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Passo 3: Pesquise com distância vetorial
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Esse é o pipeline inteiro: dados no SQL, embeddings gerados no SQL, busca por similaridade no SQL. Sem camada de orquestração, sem ETL, sem banco de dados vetorial separado.

Formatos de API e Opções Suportadas

Em GA, API_FORMAT suporta Azure OpenAI e OpenAI. MODEL_TYPE está bloqueado em EMBEDDINGS por enquanto. O JSON PARAMETERS permite definir padrões a nível de modelo incluindo o número de tentativas:

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

A autenticação usa credenciais do banco de dados, portanto os segredos ficam fora do código da aplicação.

O Que Isso Habilita para Aplicações .NET

Para desenvolvedores .NET construindo funcionalidades de IA em dados SQL existentes, isso é significativo. Você não precisa:

Extrair dados para um armazenamento intermediário para embeddings
Gerenciar uma pipeline de embeddings externa
Configurar um banco de dados vetorial separado (embora você possa usar Azure AI Search se quiser um armazenamento vetorial completo)
Alterar a camada de acesso a dados da sua aplicação

Você pode adicionar busca semântica a aplicações SQL existentes de forma incremental, usando as mesmas ferramentas T-SQL que você já tem.

Conclusão

Os padrões RAG em dados SQL ficaram dramaticamente mais simples. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL significa que sua aplicação SQL existente pode ganhar capacidades de busca vetorial sem adicionar nova infraestrutura.

Ambas as funcionalidades estão em GA no Azure SQL Database e Azure SQL Managed Instance hoje.

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

Azure Data Studio foi descontinuado: migre seu fluxo de Azure SQL para o VS Code

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

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Azure Data Studio foi descontinuado em 6 de fevereiro de 2025, com suporte até 28 de fevereiro de 2026 — o substituto recomendado é o VS Code com a extensão MSSQL.

O que instalar

Três itens para começar:

Extensão MSSQL — pesquise “SQL Server (mssql)” no Marketplace do VS Code
Extensão SQL Database Projects — esquema como código, validação de build, publicação guiada
.NET 8 SDK — exigido pelo sistema de build; SDK ausente é o problema mais comum no primeiro uso

Migrar suas conexões e configurações do ADS

A extensão MSSQL inclui o ADS Migration Toolkit, que gerencia a migração única em um fluxo guiado: conexões salvas, grupos de conexões, configurações e atalhos de teclado são importados automaticamente.

Recuperar a memória muscular do F5

Os usuários do ADS dependem do F5 para executar consultas. Instale a extensão MSSQL Database Management Keymap para recuperar os atalhos de teclado no estilo ADS, incluindo o F5.

SQL Database Projects: esquema como código

Clique com o botão direito em um projeto → Publicar → configurar destino → revisar o script T-SQL gerado → implantar. A visualização prévia do script antes da implantação é o principal recurso de segurança. Os modelos de itens geram stubs para tabelas, stored procedures e views — o mesmo fluxo do SSDT.

Problema comum: uma incompatibilidade de plataforma de destino no arquivo .sqlproj causará erros de build se o projeto foi criado para uma versão diferente do SQL Server.

Schema Compare e Schema Designer

A extensão também inclui Schema Compare (diff entre seu projeto e o banco de dados implantado) e Schema Designer (edição visual do esquema sem escrever DDL manualmente).

Desenvolvedores do Microsoft Fabric

A configuração é idêntica, mas comece pelo portal do Fabric e conecte o banco de dados ao Git primeiro antes de abri-lo no VS Code. A Microsoft tem um guia dedicado: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Conclusão

A migração é um fluxo guiado de uma única vez, não uma reconstrução manual. Instale as três ferramentas, execute o ADS Migration Toolkit, restaure seus atalhos de teclado e você estará de volta ao normal em menos de 10 minutos.

Consulte o artigo completo para capturas de tela passo a passo e o tutorial específico do Fabric.

SQL MCP Server no Azure App Service — Sem Contêineres

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

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Vou ser honesto contigo: toda vez que vejo “requer um contêiner” em um tutorial, uma pequena parte de mim suspira. Contêineres são ótimos — até que a sua equipe não tem uma estratégia de contêineres, e de repente uma funcionalidade que parecia simples fica bloqueada por sobrecarga de orquestração que ninguém planejou.

Por isso esse aqui chamou minha atenção. O SQL MCP Server agora pode rodar no Azure App Service — sem Docker, sem Kubernetes, apenas com a mesma configuração do Data API Builder (DAB) que expõe seu banco de dados SQL via MCP, REST e GraphQL.

O que é o SQL MCP Server?

Contexto rápido se você ainda não o conhece. O SQL MCP Server fica entre o seu agente de IA e o seu banco de dados SQL. Em vez de dar ao agente acesso direto ao banco (o que seria uma péssima ideia), ele expõe suas tabelas e views como uma camada de abstração — entidades com permissões definidas.

É construído sobre o Data API Builder, o que significa que um único arquivo de configuração gerencia MCP e REST e GraphQL simultaneamente. Seu agente fala com o endpoint MCP. Sua aplicação tradicional fala com REST ou GraphQL. Mesma config, mesmo runtime, superfícies diferentes.

Isso é genuinamente útil. Você não mantém duas camadas de API separadas.

O Problema do Contêiner (e a Solução)

O modelo de deployment original do SQL MCP Server usava contêineres. Funciona bem em muitas equipes — mas não em todas. Muitas equipes .NET padronizam no Azure App Service ou VMs. Exigir um runtime de contêiner apenas para expor um endpoint SQL adiciona fricção que ninguém pediu.

O novo tutorial mostra como pular o contêiner completamente. Tudo funciona com um comando dab start, hospedado no App Service como um processo web .NET 8 padrão.

# Instalar Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inicializar a configuração
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Adicionar uma entidade
dab add products --source dbo.products --permissions "authenticated:*"

# Configurar o provedor de auth do App Service
dab configure --runtime.host.authentication.provider AppService

# Iniciar o servidor
dab start

Neste ponto você tem MCP em /mcp, REST e GraphQL do mesmo processo, e nada rodando em contêiner.

Autenticação Sem Chaves de API Compartilhadas

Essa é a parte que mais aprecio. Ao fazer o deploy no App Service, você configura o Microsoft Entra ID como provedor de autenticação. Sem segredos compartilhados em arquivos de configuração, sem chaves de API para rotacionar.

A string de conexão fica em uma variável de ambiente do App Service (não no dab-config.json), e o endpoint MCP é protegido pela autenticação da plataforma. Se você já está alinhado com o Entra ID em suas cargas de trabalho Azure, isso se encaixa naturalmente.

Para desenvolvimento local, você muda para o modo Simulator e transporte STDIO. Volta para o modo AppService antes do deploy. Limpo e explícito.

Deploy no App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

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

Depois você faz o deploy do seu projeto DAB usando o método de deployment de código que sua equipe já usa. O detalhe importante: é um deployment de código, não de contêiner.

Por que Isso Importa para Desenvolvedores .NET

Se você está construindo agentes de IA em .NET, eventualmente seu agente precisará falar com um banco de dados. O SQL MCP Server te dá uma maneira estruturada de fazer isso sem expor strings de conexão brutas.

Confira o tutorial completo no post original e o repositório de exemplo no GitHub.

Conclusão

O SQL MCP Server no App Service é uma opção pragmática sólida para equipes .NET que querem dar aos seus agentes acesso estruturado a dados SQL sem uma estratégia de contêineres. Experimente — seus agentes vão apreciar a superfície de API limpa.

SQL Server 2025 como Banco de Dados Pronto para Agentes: Segurança, Backup e MCP em Um Motor

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

Esta postagem foi traduzida automaticamente. Para a versão original, clique aqui.

Acompanhei a série Polyglot Tax de Aditya Badramraju com muito interesse. A parte 4 fecha a série com as partes que realmente determinam se você confiaria nessa arquitetura em produção.

Um Modelo de Segurança para Todos os Modelos de Dados

Uma única política de Row-Level Security que cobre todos os modelos de dados. Uma política, uma prova para o auditor.

Backup Unificado = Recuperação Atômica

Em um stack poliglota, recuperação point-in-time em cinco bancos de dados é um pesadelo de consistência. Com um banco, é atômica por definição.

Integração MCP: Agentes Sem Middleware

SQL Server 2025 suporta o SQL MCP Server diretamente. Agentes chamam ferramentas, o motor impõe isolamento de tenant e mascaramento de colunas automaticamente.

Post original de Aditya Badramraju: The Polyglot Tax – Part 4.

SQL MCP Server — A forma certa de dar acesso a bancos de dados para agentes de IA

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Vamos ser honestos: a maioria dos servidores MCP de banco de dados disponíveis hoje são assustadores. Eles pegam uma consulta em linguagem natural, geram SQL na hora e executam contra seus dados de produção. O que poderia dar errado? (Tudo. Tudo poderia dar errado.)

O time do Azure SQL acabou de apresentar o SQL MCP Server, e ele adota uma abordagem fundamentalmente diferente. Construído como uma funcionalidade do Data API builder (DAB) 2.0, dá aos agentes de IA acesso estruturado e determinístico a operações de banco de dados — sem NL2SQL, sem expor seu esquema, e com RBAC completo em cada etapa.

Por que não NL2SQL?

Essa é a decisão de design mais interessante. Modelos não são determinísticos, e consultas complexas são as mais propensas a produzir erros sutis. As consultas exatas que os usuários esperam que a IA gere são também as que precisam de mais escrutínio quando produzidas de forma não determinística.

Em vez disso, o SQL MCP Server usa uma abordagem NL2DAB. O agente trabalha com a camada de abstração de entidades do Data API builder e seu construtor de consultas integrado para produzir T-SQL preciso e bem formado de maneira determinística. Mesmo resultado para o usuário, mas sem o risco de JOINs alucinados ou exposição acidental de dados.

Sete ferramentas, não setecentas

O SQL MCP Server expõe exatamente sete ferramentas DML, independentemente do tamanho do banco de dados:

describe_entities — descobrir entidades e operações disponíveis
create_record — inserir linhas
read_records — consultar tabelas e views
update_record — modificar linhas
delete_record — remover linhas
execute_entity — executar stored procedures
aggregate_records — consultas de agregação

Isso é inteligente porque janelas de contexto são o espaço de pensamento do agente. Inundá-las com centenas de definições de ferramentas deixa menos espaço para raciocínio. Sete ferramentas fixas mantêm o agente focado em pensar em vez de navegar.

Cada ferramenta pode ser habilitada ou desabilitada individualmente:

"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
 }
 }
}

Começando em três comandos

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

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

dab start

Isso é um SQL MCP Server rodando e expondo sua tabela Customers. A camada de abstração de entidades significa que você pode criar aliases para nomes e colunas, limitar campos por papel, e controlar exatamente o que os agentes veem — sem expor detalhes internos do esquema.

A história de segurança é sólida

É aqui que a maturidade do Data API builder compensa:

RBAC em cada camada — cada entidade define quais papéis podem ler, criar, atualizar ou deletar, e quais campos são visíveis
Integração com Azure Key Vault — strings de conexão e segredos gerenciados com segurança
Microsoft Entra + OAuth personalizado — autenticação de nível de produção
Content Security Policy — agentes interagem através de um contrato controlado, não SQL cru

A abstração de esquema é particularmente importante. Seus nomes internos de tabelas e colunas nunca são expostos ao agente. Você define entidades, aliases e descrições que fazem sentido para a interação com IA — não seu diagrama ERD do banco de dados.

Multi-banco e multi-protocolo

O SQL MCP Server suporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E como é uma funcionalidade do DAB, você obtém endpoints REST, GraphQL e MCP simultaneamente da mesma configuração. Mesmas definições de entidades, mesmas regras RBAC, mesma segurança — nos três protocolos.

A auto-configuração no DAB 2.0 pode até inspecionar seu banco de dados e construir a configuração dinamicamente, se você estiver confortável com menos abstração para prototipagem rápida.

Minha opinião

É assim que o acesso empresarial a bancos de dados para agentes de IA deveria funcionar. Não “ei LLM, escreve SQL pra mim e YOLO contra produção.” Em vez disso: uma camada de entidades bem definida, geração determinística de consultas, RBAC em cada etapa, cache, monitoramento e telemetria. É chato da melhor maneira possível.

Para desenvolvedores .NET, a história de integração é limpa — DAB é uma ferramenta .NET, o MCP Server roda como contêiner, e funciona com Azure SQL, que a maioria de nós já está usando. Se você está construindo agentes de IA que precisam de acesso a dados, comece aqui.

Finalizando

SQL MCP Server é gratuito, open-source e roda em qualquer lugar. É a abordagem prescritiva da Microsoft para dar aos agentes de IA acesso seguro a bancos de dados. Confira o post completo e a documentação para começar.