Azure SQL | The .NET Blog

NL2SQL Es la Inyección SQL de la Era Agéntica

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

Hay una versión del argumento de NL2SQL que suena perfecta: los usuarios hacen preguntas en lenguaje natural, los agentes generan SQL, los datos regresan. Menos pantallas, menos consultas, menos código. Simple.

Luego lo piensas cinco minutos más.

Los Problemas de los que Nadie Habla en la Demo

Los esquemas no fueron diseñados para explicar las cosas. Nombres de tablas crípticos, nombres de columnas inconsistentes, relaciones técnicamente válidas pero semánticamente inválidas sin predicados adicionales — esto es normal en bases de datos empresariales. No son errores, son simplemente la historia acumulada de cambios de negocio. Pero cuando le pides a un modelo que infiera intención de un esquema que no fue diseñado para comunicar intención, el modelo lo intentará de todas formas. No se rendirá. Generará su mejor consulta posible y devolverá resultados con confianza.

Los modelos no son deterministas. Haz la misma pregunta sobre la misma base de datos dos veces y podrías obtener SQL diferente. El modelo está calculando probabilidades, y variaciones ligeras en el contexto generan salidas diferentes. No puedes probar tu camino hacia una garantía de que el agente siempre genera la consulta correcta.

La revisión del usuario no escala. “Solo revisa cada consulta antes de la ejecución” suena seguro. Pero asume que los usuarios son expertos tanto en el modelo de datos como en SQL — exactamente las personas que no necesitaban la interfaz de lenguaje natural. También introduce sobrecarga cognitiva y una nueva clase de sesgo de confirmación, donde los usuarios abrumados por la complejidad de la consulta aprueban consultas inválidas en lugar de investigarlas.

Y luego está la inyección. En el desarrollo SQL tradicional, la parametrización resolvió la inyección porque la entrada del usuario llenaba parámetros, no la estructura SQL. Con NL2SQL, el modelo genera el SQL en sí. El prompt, el contexto del esquema, el historial de conversación y los datos recuperados influyen en lo que se ejecuta. Si alguien elabora un prompt que cambia lo que el modelo genera, eso es inyección — no a nivel de parámetro, sino a nivel de generación de consultas. Y a diferencia de eliminar una tabla (obvio, recuperable), la inyección NL2SQL produce consultas que devuelven resultados incorrectos sin ningún error visible. Las decisiones de negocio se toman sobre datos incorrectos.

Lo que SQL MCP Server Realmente Resuelve

Aquí es donde el artículo hace su punto práctico más útil. En lugar de dar a un agente acceso arbitrario al esquema y esperar lo mejor, SQL MCP Server expone una superficie API curada construida sobre Data API builder.

La diferencia importa: el agente no genera SQL. Llama a endpoints con nombre que devuelven formas de resultado predefinidas. El SQL se escribe una vez, por un desarrollador, y es determinista. El no-determinismo del agente se limita a elegir qué endpoint llamar, no a construir consultas arbitrarias.

Esto es análogo a lo que la parametrización hizo para la inyección SQL en el modelo de aplicación tradicional — eliminas la capacidad de construir consultas arbitrarias a partir de entrada no confiable.

La Pregunta Correcta

El artículo no dice “nunca uses NL2SQL.” Dice: sé deliberado sobre dónde lo aplicas y qué expones. Para análisis exploratorio en un entorno controlado, con un esquema limitado y acceso de solo lectura, NL2SQL podría estar bien. Para sistemas de producción donde las decisiones de negocio dependen de los resultados, una capa API curada es significativamente más segura.

Honestidad: algunos problemas se resuelven genuinamente mejor con consultas estructuradas detrás de endpoints con nombre que con lenguaje natural a SQL. SQL MCP Server te da esa opción sin abandonar completamente la interfaz agéntica.

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

Azure SQL Puede Generar Embeddings Ahora — En T-SQL Puro, Sin Capa de Aplicación

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

Si alguna vez has construido un pipeline RAG, conoces el impuesto del pipeline: tus datos viven en SQL, pero para generar embeddings necesitas extraerlos, llamar a una API de embeddings, gestionar lotes y límites de velocidad, y almacenar los resultados en algún lugar con búsqueda vectorial. A menudo en una base de datos completamente diferente.

Azure SQL acaba de eliminar la mayor parte de eso con dos características que ahora están generalmente disponibles: CREATE EXTERNAL MODEL y AI_GENERATE_EMBEDDINGS.

Qué Hacen

Estas dos características de T-SQL funcionan como un pipeline integrado:

CREATE EXTERNAL MODEL — registra un endpoint de modelo de IA externo como un objeto de base de datos con nombre. Estableces la ubicación, el formato de API, el tipo de modelo y las credenciales una vez. Lo reutilizas en cualquier lugar.

AI_GENERATE_EMBEDDINGS — una función T-SQL escalar que llama al modelo registrado y devuelve una matriz JSON de valores vectoriales. Funciona en sentencias SELECT, INSERT, UPDATE y MERGE.

Juntos forman un pipeline de embeddings de extremo a extremo sin salir del motor SQL.

El Flujo de Trabajo Completo

-- Paso 1: Registra tu proveedor de embeddings una 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'
);

-- Paso 2: Genera embeddings en línea en T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Paso 3: Busca con distancia vectorial
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Ese es todo el pipeline: datos en SQL, embeddings generados en SQL, búsqueda de similitud en SQL. Sin capa de orquestación, sin ETL, sin base de datos vectorial separada.

Formatos de API y Opciones Soportadas

En GA, API_FORMAT soporta Azure OpenAI y OpenAI. MODEL_TYPE está bloqueado a EMBEDDINGS por ahora. El JSON PARAMETERS te permite establecer valores predeterminados a nivel de modelo incluyendo el conteo de reintentos:

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

La autenticación usa credenciales de base de datos, por lo que los secretos se mantienen fuera del código de tu aplicación.

Qué Habilita Esto para las Aplicaciones .NET

Para los desarrolladores .NET que construyen características de IA sobre datos SQL existentes, esto es significativo. No necesitas:

Extraer datos a un almacén intermedio para embeddings
Gestionar un pipeline de embeddings externo
Configurar una base de datos vectorial separada (aunque puedes usar Azure AI Search si quieres un almacén vectorial completo)
Cambiar la capa de acceso a datos de tu aplicación

Puedes agregar búsqueda semántica a las aplicaciones SQL existentes de manera incremental, usando las mismas herramientas T-SQL que ya tienes.

Conclusión

Los patrones RAG sobre datos SQL se han vuelto dramáticamente más simples. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL significa que tu aplicación SQL existente puede ganar capacidades de búsqueda vectorial sin agregar nueva infraestructura.

Ambas características están en GA en Azure SQL Database y Azure SQL Managed Instance hoy.

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

Azure Data Studio se retira: mueve tu flujo de Azure SQL a VS Code

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Azure Data Studio se retiró el 6 de febrero de 2025, con soporte hasta el 28 de febrero de 2026 — el reemplazo recomendado es VS Code con la extensión MSSQL.

Qué instalar

Tres cosas para empezar:

Extensión MSSQL — busca “SQL Server (mssql)” en el Marketplace de VS Code
Extensión SQL Database Projects — esquema como código, validación de compilación, publicación guiada
.NET 8 SDK — requerido por el sistema de compilación; el SDK faltante es el problema más común al primer uso

Migrar tus conexiones y configuraciones de ADS

La extensión MSSQL incluye el ADS Migration Toolkit, que gestiona la migración única en un flujo guiado: conexiones guardadas, grupos de conexiones, configuraciones y atajos de teclado se importan automáticamente.

Recuperar el músculo del F5

Los usuarios de ADS dependen de F5 para ejecutar consultas. Instala la extensión MSSQL Database Management Keymap para recuperar los atajos de teclado al estilo ADS, incluido F5.

SQL Database Projects: esquema como código

Clic derecho en un proyecto → Publicar → configurar destino → revisar el script T-SQL generado → desplegar. La vista previa del script antes del despliegue es la característica clave de seguridad. Las plantillas de elementos generan esqueletos para tablas, procedimientos almacenados y vistas — el mismo flujo que SSDT.

Problema frecuente: una incompatibilidad de plataforma de destino en el archivo .sqlproj causará errores de compilación si el proyecto fue creado contra una versión diferente de SQL Server.

Schema Compare y Schema Designer

La extensión también incluye Schema Compare (diferencia entre tu proyecto y la base de datos desplegada) y Schema Designer (edición visual del esquema sin escribir DDL a mano).

Desarrolladores de Microsoft Fabric

La configuración es idéntica, pero comienza desde el portal de Fabric y conecta la base de datos a Git primero antes de abrirla en VS Code. Microsoft tiene una guía dedicada: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Conclusión

La migración es un flujo guiado de una sola vez, no una reconstrucción manual. Instala las tres herramientas, ejecuta el ADS Migration Toolkit, restaura tus atajos de teclado y estarás de vuelta a la normalidad en menos de 10 minutos.

Consulta el artículo completo para capturas de pantalla paso a paso y el tutorial específico de Fabric.

Este cambio ayuda cuando hay que equilibrar velocidad de entrega, consistencia de plataforma y gobernanza.

Siguientes pasos practicos

Valida la funcionalidad en un piloto .NET pequeno con datos realistas.
Define observabilidad y un plan de rollback antes de escalar.
Documenta el patron para reutilizarlo en otros equipos.

Fuente

Articulo original: https://devblogs.microsoft.com/azure-sql/azure-data-studio-is-retired-move-your-azure-sql-workflow-to-vs-code-in-10-minutes/

SQL MCP Server en Azure App Service — Sin Contenedores

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

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Seré honesto contigo: cada vez que veo “requiere un contenedor” en un tutorial, una pequeña parte de mí suspira. Los contenedores son geniales, hasta que tu equipo no tiene una estrategia de contenedores, y de repente una funcionalidad que parecía simple está bloqueada por una sobrecarga de orquestación que no habías planeado.

Por eso esto me llamó la atención. El SQL MCP Server ahora puede ejecutarse en Azure App Service — sin Docker, sin Kubernetes, solo la misma configuración de Data API Builder (DAB) que expone tu base de datos SQL a través de MCP, REST y GraphQL.

¿Qué es el SQL MCP Server?

Contexto rápido si aún no lo conoces. El SQL MCP Server se sitúa entre tu agente de IA y tu base de datos SQL. En lugar de darle a tu agente acceso directo a la base de datos (lo cual es terrible idea), expone tus tablas y vistas como una capa de abstracción — entidades con permisos definidos.

Está construido sobre Data API builder, lo que significa que un único archivo de configuración gestiona MCP y REST y GraphQL simultáneamente. Tu agente habla con el endpoint MCP. Tu aplicación tradicional habla con REST o GraphQL. Misma config, mismo runtime, superficies diferentes.

Eso es genuinamente útil. No estás manteniendo dos capas de API separadas.

El Problema del Contenedor (y la Solución)

El modelo de despliegue original del SQL MCP Server era con contenedores. Funciona bien en muchos equipos, pero no en todos. Muchos equipos .NET estandarizan en Azure App Service o VMs. Requerir un runtime de contenedor solo para exponer un endpoint SQL agrega fricción que nadie pidió.

El nuevo tutorial muestra cómo saltarte el contenedor por completo. Todo funciona con un comando dab start, alojado en App Service como un proceso web .NET 8 estándar.

Aquí está el flujo de configuración local en pocas palabras:

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

# Inicializar la configuración
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Agregar una entidad
dab add products --source dbo.products --permissions "authenticated:*"

# Configurar el proveedor de auth de App Service
dab configure --runtime.host.authentication.provider AppService

# Iniciar el servidor
dab start

En este punto tienes MCP en /mcp, REST y GraphQL desde el mismo proceso, y nada corriendo en un contenedor.

Autenticación Sin Claves de API Compartidas

Esta es la parte que más aprecio. Cuando despliegas en App Service, configuras Microsoft Entra ID como proveedor de autenticación. Sin secretos compartidos en archivos de configuración, sin claves de API que rotar.

La cadena de conexión permanece en una variable de entorno de App Service (no en dab-config.json), y el endpoint MCP está protegido por autenticación de plataforma. Si ya estás alineado con Entra ID en tus cargas de trabajo de Azure — lo cual probablemente sea el caso si usas agentes de Azure AI Foundry — esto encaja naturalmente.

Para el desarrollo local, cambias al modo Simulator y transporte STDIO. Vuelves al modo AppService cuando despliegas. Limpio y explícito.

Despliegue en App Service

El despliegue real es trabajo estándar con Azure CLI:

# Crear el plan de App Service
az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

# Crear la aplicación web (runtime .NET 8)
az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

# Configurar el comando de inicio
az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Luego despliega tu proyecto DAB usando el método de despliegue que tu equipo ya usa — VS Code, GitHub Actions, Zip Deploy. El detalle clave: es un despliegue de código, no de contenedor. Sin imagen que construir, publicar ni gestionar.

Por qué Importa para los Desarrolladores .NET

Si estás construyendo agentes de IA en .NET — ya sea con el Microsoft Agent Framework, Semantic Kernel, o agentes hospedados en Azure AI Foundry — eventualmente tu agente necesita hablar con una base de datos. El SQL MCP Server te da una manera estructurada de hacer eso sin exponer cadenas de conexión en bruto ni escribir una capa de API personalizada.

Ejecutarlo en App Service cierra la brecha para equipos que no trabajan con contenedores. Es la misma configuración de DAB, la misma auth de Entra, el mismo protocolo MCP — solo en infraestructura que ya conoces.

Consulta el tutorial completo en el post original del blog y el repositorio de muestra en GitHub.

Conclusión

El SQL MCP Server en App Service es una opción pragmática sólida para equipos .NET que quieren dar a sus agentes acceso estructurado a datos SQL sin una estrategia de contenedores. La combinación del modelo de entidades de DAB, la auth integrada de Entra en App Service, y el comando de inicio dab start resulta en un despliegue simple de explicar y fácil de operar.

Pruébalo. Tus agentes apreciarán la superficie de API limpia. Tu equipo de operaciones apreciará no tener que lidiar con registros de contenedores.

SQL Server 2025 como Base de Datos Lista para Agentes: Seguridad, Backup y MCP en un Solo Motor

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

He seguido la serie Polyglot Tax de Aditya Badramraju con mucho interés. Las partes 1-3 construyeron un caso convincente para SQL Server 2025 como una base de datos genuinamente multi-modelo. La parte 4 cierra la serie con las partes que realmente determinan si confiarías en esta arquitectura en producción.

Un Modelo de Seguridad para Todos los Modelos de Datos

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Customers,
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Events,
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Relationships,
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Embeddings
WITH (STATE = ON);

Una política, una prueba. Para un auditor que pregunta “demuestra que el Tenant A no puede ver los datos del Tenant B”, esto es oro.

Backup Unificado = Recuperación Atómica

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

En un stack políglota, coordinar la recuperación de cinco bases de datos es una pesadilla de consistencia. Con una sola base de datos y un log de transacciones, la recuperación es atómica por definición.

Integración MCP: Agentes Sin Middleware Codificado a Mano

SQL Server 2025 soporta el SQL MCP Server directamente. Los agentes llaman herramientas, el motor impone aislamiento de tenant y enmascaramiento de columnas automáticamente.

Resumiendo

Para desarrolladores .NET construyendo aplicaciones con agentes en Azure SQL, esta arquitectura merece consideración seria. Post original de Aditya Badramraju: The Polyglot Tax – Part 4.

SQL MCP Server — La forma correcta de darle acceso a bases de datos a los agentes de IA

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Seamos honestos: la mayoría de los servidores MCP de bases de datos disponibles hoy son aterradores. Toman una consulta en lenguaje natural, generan SQL al vuelo y lo ejecutan contra tus datos de producción. ¿Qué podría salir mal? (Todo. Todo podría salir mal.)

El equipo de Azure SQL acaba de presentar SQL MCP Server, y toma un enfoque fundamentalmente diferente. Construido como una característica de Data API builder (DAB) 2.0, da a los agentes de IA acceso estructurado y determinista a operaciones de base de datos — sin NL2SQL, sin exponer tu esquema, y con RBAC completo en cada paso.

¿Por qué no NL2SQL?

Esta es la decisión de diseño más interesante. Los modelos no son deterministas, y las consultas complejas son las más propensas a producir errores sutiles. Las consultas exactas que los usuarios esperan que la IA genere son también las que necesitan más escrutinio cuando se producen de forma no determinista.

En su lugar, SQL MCP Server usa un enfoque NL2DAB. El agente trabaja con la capa de abstracción de entidades de Data API builder y su constructor de consultas integrado para producir T-SQL preciso y bien formado de manera determinista. Mismo resultado para el usuario, pero sin el riesgo de JOINs alucinados o exposición accidental de datos.

Siete herramientas, no setecientas

SQL MCP Server expone exactamente siete herramientas DML, sin importar el tamaño de la base de datos:

describe_entities — descubrir entidades y operaciones disponibles
create_record — insertar filas
read_records — consultar tablas y vistas
update_record — modificar filas
delete_record — eliminar filas
execute_entity — ejecutar procedimientos almacenados
aggregate_records — consultas de agregación

Esto es inteligente porque las ventanas de contexto son el espacio de pensamiento del agente. Inundarlas con cientos de definiciones de herramientas deja menos espacio para el razonamiento. Siete herramientas fijas mantienen al agente enfocado en pensar en lugar de navegar.

Cada herramienta puede habilitarse o deshabilitarse 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
 }
 }
}

Empezando en tres comandos

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

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

dab start

Eso es un SQL MCP Server funcionando y exponiendo tu tabla Customers. La capa de abstracción de entidades significa que puedes crear alias para nombres y columnas, limitar campos por rol, y controlar exactamente lo que ven los agentes — sin exponer detalles internos del esquema.

La historia de seguridad es sólida

Aquí es donde la madurez de Data API builder da frutos:

RBAC en cada capa — cada entidad define qué roles pueden leer, crear, actualizar o eliminar, y qué campos son visibles
Integración con Azure Key Vault — cadenas de conexión y secretos gestionados de forma segura
Microsoft Entra + OAuth personalizado — autenticación de nivel producción
Content Security Policy — los agentes interactúan a través de un contrato controlado, no SQL crudo

La abstracción del esquema es particularmente importante. Los nombres internos de tus tablas y columnas nunca se exponen al agente. Defines entidades, alias y descripciones que tienen sentido para la interacción con IA — no tu diagrama ERD de la base de datos.

Multi-base de datos y multi-protocolo

SQL MCP Server soporta Microsoft SQL, PostgreSQL, Azure Cosmos DB y MySQL. Y como es una característica de DAB, obtienes endpoints REST, GraphQL y MCP simultáneamente desde la misma configuración. Mismas definiciones de entidades, mismas reglas RBAC, misma seguridad — en los tres protocolos.

La auto-configuración en DAB 2.0 puede incluso inspeccionar tu base de datos y construir la configuración dinámicamente, si te resulta cómodo menos abstracción para prototipado rápido.

Mi opinión

Así es como debería funcionar el acceso empresarial a bases de datos para agentes de IA. No “hey LLM, escríbeme algo de SQL y YOLO contra producción.” En su lugar: una capa de entidades bien definida, generación determinista de consultas, RBAC en cada paso, caché, monitoreo y telemetría. Es aburrido de la mejor manera posible.

Para desarrolladores .NET, la historia de integración es limpia — DAB es una herramienta .NET, el MCP Server se ejecuta como contenedor, y funciona con Azure SQL, que la mayoría ya estamos usando. Si estás construyendo agentes de IA que necesitan acceso a datos, empieza aquí.

Para cerrar

SQL MCP Server es gratuito, de código abierto y se ejecuta en cualquier lugar. Es el enfoque prescriptivo de Microsoft para dar acceso seguro a bases de datos a los agentes de IA. Consulta el post completo y la documentación para empezar.