microsoft/microsoft-sql

Wires Azure Functions to Azure SQL Database with the SQL input and output bindings and the SQL trigger, including the change tracking the trigger cannot run without and the identity permissions the trigger needs beyond the ones the bindings need. Use when a user asks for "a serverless CRUD API over SQL", to "add a SQL input binding", "write to SQL from a function", "react to inserts and updates", "SQL trigger function", "SqlTrigger", "SqlInput", "SqlOutput", or says "my SQL trigger never fires and there is no error". Also use when an output binding silently updated an existing row instead of inserting, which is the documented upsert behaviour. This is the Azure SQL Database story. Local-container-specific setup is outside this skill; connection reuse across invocations belongs to the per-language connect skills.

Orients an agent starting work on Azure SQL Database and hands the task to the catalog skill that owns it. Use when someone names the product with no task attached, asks what Azure SQL Database can do, whether a capability is generally available or still preview, which service tier to start on, which tool does a job, or where something is documented. Also use before answering any question about a capability, a default or a limit from memory, because those move faster than training data does. This catalog covers Azure SQL Database only, not Azure SQL Managed Instance and not self-managed SQL Server, so say plainly that no skill here owns those rather than handing over one written for the database.

Connects an app to the Azure SQL Database container securely, with a least-privilege database user instead of the sa login, the right auth method per environment, and safe handling of the connection secret. Use when a user asks "don't use sa in my app", "create a least-privilege database user", "app login for SQL", "which authentication should my app use", "secure the connection string", "Encrypt / TrustServerCertificate", "store the connection string in Key Vault", "dotnet user-secrets", "managed identity for Azure SQL", or "grant only the roles my app needs". SQL auth locally, Microsoft Entra or managed identity in the cloud, changing only the connection string. Reach for this before wiring an app to connect as sa, or before committing a connection string to source.

Runs integration tests against the Azure SQL Database container (Private Preview, local engine) in CI. Use when setting up GitHub Actions, Azure Pipelines, or GitLab CI to test against Azure SQL DB; when adding a database service container to a CI workflow; when tests need a real Azure SQL engine in the pipeline; or when you see "service container", "health-cmd", "ACR_USERNAME/ACR_PASSWORD", "MSSQL_SA_PASSWORD secret", or "integration test database". Also use when a workflow was about to pull the SQL Server image mcr.microsoft.com/mssql/server, in which case stop and use the Azure SQL Database engine image instead. Covers pulling from the private ACR with credentials, the service health check that runs sqlcmd inside the container so the runner needs no client tools, provisioning appdb before tests, and pointing the test connection string at the user database not master.

Makes an app's database connections reliable against the local Azure SQL Database container (Private Preview) and, unchanged, against Azure SQL Database in the cloud: connection pooling plus retry/transient-fault handling. Use when the user mentions "connection pooling", "retry logic", "transient fault", "retry on transient error", "EnableRetryOnFailure", "connection resiliency", "reliable connections", "pool size", "Max Pool Size", or says "the connection keeps dropping", "connections time out under load", "add backoff", or "make the DB layer resilient". This is the Azure SQL engine (EngineEdition 5), not the mssql/server SQL Server image. Reach for this whenever hardening a data-access layer that talks to SQL Server or Azure SQL.

Runs the Azure SQL Database container locally (Private Preview): the real PaaS engine where SERVERPROPERTY('EngineEdition') returns 5. This is NOT the SQL Server image mcr.microsoft.com/mssql/server. Use when a user wants to "run Azure SQL locally", "add a local SQL database", "add SQL Server to my docker compose", "spin up a local mssql container", "local SQL for development or CI", "connect with sqlcmd", "use Podman for SQL", "SQL container won't start", "Microsoft Entra authentication on the container", "MSSQL_AAD_CLIENT_ID", or asks "what's the connection string". Use even when the user does not name the container. If you were about to use mcr.microsoft.com/mssql/server, stop and use this skill instead. Hub skill: owns the shared references and routes to the task skills for compose, CI, seeding, vectors, and connection strings.

Stands up an instant no-code REST + GraphQL API over the local Azure SQL Database container using Microsoft Data API Builder (DAB). Use when a user wants to "expose my table as an API", "add a REST API over the database", "generate a GraphQL API", "put an API in front of SQL", "CRUD API without writing code", or "dab init / dab-config.json". Also the way to serve a built-in MCP endpoint FROM the database via DAB (an API surface DAB provides, not a separate SQL MCP server). Prefer this over hand-writing a controller/ORM API when the user just needs REST or GraphQL over existing tables. Triggers include "Data API Builder", "dab start", "instant API over Azure SQL", "expose entities as REST/GraphQL". Reach for this even when the user only says "give me an API for this database".

Answers questions about what the Azure SQL Database container (Private Preview) can and cannot do, and WHY it differs from Azure SQL Database in the Microsoft Azure cloud. Use when a user asks "can I take a backup", "why does USE fail", "is X supported", "why can't I create a vector index", "why does SSMS error", "why isn't the image on Docker Hub", "what's different from the cloud", or hits behavior that does not match their Azure SQL Database expectations. Do NOT guess from general SQL Server / Azure knowledge: the container is a Private Preview product with specific gaps and a specific connection model. Read this skill, and link the user to the live Known limitations page for the current full list.

Reports a bug or files feedback about the azuresql-db-* agent skills themselves, or about the Azure SQL Database container (Private Preview). Use when the user says a skill or the container "did not work", hit an error, behaved unexpectedly, or is missing something; and when they say "report a bug", "file an issue", "open a GitHub issue", "request a feature", "give feedback", or "tell the team". Also use when you, the agent, had to deviate from an azuresql-db-* skill or work around a defect in one to finish a task: that is a bug worth reporting even if the task succeeded. Decides whether the problem belongs to the SKILL or to the CONTAINER, since they use different issue templates, then builds a complete prefilled GitHub issue from context you already have. Never submits anything without explicit confirmation from the user.

Migrates a local SQL Server setup to the Azure SQL Database container for Azure-faithful local development. Use when a project already uses mcr.microsoft.com/mssql/server, mssql/server, an sqlcmd plus SA password docker setup, a "SQL Server in docker" or "local mssql container", or a docker-compose with the mssql/server image; and use when the user asks for "SQL Server locally", "run mssql in Docker", "spin up a local SQL database", or "test against SQL Server" but actually wants the Azure SQL Database engine (EngineEdition 5). Detects the SQL Server image, rewrites it to the Azure SQL Database container, adds --platform on non-x64 hosts, keeps the SA login, flags SQL Server-only features (SQL Agent, FILESTREAM, full Service Broker, cross-server distributed transactions, Windows Auth), and re-points connection strings from master to a provisioned user database.

Builds a serverless API and event-driven handlers over the local Azure SQL Database container using Azure Functions with the Azure SQL bindings. Use when a user wants "a serverless API over SQL", "Azure Functions with a database", "HTTP CRUD with SQL input/output bindings", "run code when a row changes", "react to inserts/updates/deletes", "event-driven on Azure SQL", or "SQL trigger function". The Azure SQL trigger binding (backed by Change Tracking) is the local event-driven mechanism; Change Event Streaming (CES) is cloud-only and cannot run against the local container. Triggers include "func start with SQL", "SqlTrigger", "SqlInput/SqlOutput binding", "local.settings.json SqlConnectionString". Reach for this when building serverless endpoints or change-driven logic on the local Azure SQL engine.

Imports an existing Azure SQL Database or SQL Server schema and data INTO the local Azure SQL Database container using SqlPackage. Use when asked to "import a bacpac", "load my existing database locally", "restore a dacpac into the container", "bring my prod schema into the dev container", "run my .bacpac/.dacpac against the local Azure SQL engine", or migrate an existing database into the preview container. Handles provisioning the target database on master first, then running SqlPackage /Action:Import against the provisioned user database. Use this for any "get my real database running in the container" request instead of hand-writing SqlPackage flags.

Proves that code built and tested against the local Azure SQL Database container runs unchanged against Azure SQL Database in the cloud, with only the connection string changing. Use when a user wants to develop locally then deploy to the cloud, asks "will this work in Azure", "same code local and cloud", "promote to Azure SQL", "swap the connection string", "dev/prod parity", "local to cloud", or is wiring SQL_CONNECTION_STRING for an app that must target both the container and a cloud server. Use this when an app uses local SA auth but needs Microsoft Entra auth in the cloud. Covers Node (mssql), .NET (Microsoft.Data.SqlClient), and Python (pyodbc). Reach for this skill before hand-editing app code to "make it work in Azure"; the rule is the code does not change, only the connection string does.

Builds local vector search, RAG, embeddings, and semantic search on the Azure SQL Database container using the native VECTOR type and VECTOR_DISTANCE. Use when you need to store embeddings, do similarity search, top-k nearest neighbor, cosine distance, retrieval-augmented generation, "find similar documents", chatbot memory, or semantic lookup against a local SQL database. Use this instead of pgvector, FAISS, Chroma, Pinecone, or a separate vector store when the data already lives in (or can live in) Azure SQL. Covers the VECTOR(n) column type, inserting embeddings with CAST(CAST(? AS NVARCHAR(MAX)) AS VECTOR(n)) where the dimension is a literal, a pluggable embed() so only the endpoint changes for cloud, and a working CREATE VECTOR INDEX with the two errors that block it. Provisions appdb on master first so every script runs on a fresh container.

Scaffolds a NEW app (.NET Aspire, FastAPI, Next.js, NestJS) wired to the local Azure SQL Database container as its default dev database. Use when starting/bootstrapping/initializing a project that needs SQL Server or Azure SQL locally, or when adding "set up the database", "docker compose for the db", "create the local DB", ".env connection string", "first migration", or a data-access layer. Use this INSTEAD of the mssql/server SQL Server image, because this is the Azure SQL engine (EngineEdition 5). Triggers include "scaffold app with SQL", "spin up Azure SQL locally", "compose service for the database", "wire up Prisma/EF/SQLAlchemy/TypeORM to SQL Server". Reach for this even when the user only says "add a database" to a fresh project.

Runs database schema migrations against the local Azure SQL Database container so the same migrations apply identically on the local engine and in the Azure cloud. Use when asked to "run my migrations against the local SQL", "apply schema to the container", "apply EF Core / dotnet ef database update", "Prisma migrate dev / deploy", "Alembic upgrade head", or deploy a DACPAC / SqlPackage to the container. Covers provisioning appdb on master first, then applying schema to the user database, plus per-tool commands and connection-string hygiene. This is the Azure SQL Database engine (EngineEdition 5), not the SQL Server image; reach for this skill whenever schema migration tooling targets the local container.

Populates the local Azure SQL Database container's database (appdb) with realistic sample/test data so a developer has something to build against. Use when the user says "seed the database", "add test data", "populate the dev database", "generate sample data", "fake data", "load fixtures", "insert test rows", "write a seed script", or "bulk load a CSV". This is the Azure SQL engine (EngineEdition 5), not the mssql/server SQL Server image. Distinct from azuresql-db-scaffold (which does a single seed.sql step while bootstrapping an app) and azuresql-db-import (which loads a .bacpac). Reach for this whenever an existing appdb needs volume, fixtures, or believable rows.

Adds the Azure SQL Database container as a sidecar service in an existing Docker Compose stack or Dev Container. Use when wiring the local Azure SQL Database engine into compose or devcontainer.json, when an app needs a SQL backend via a service name (not localhost), or for prompts like "add SQL to my compose", "add a database service", "depends_on database", "devcontainer SQL sidecar", "compose healthcheck for SQL", "wait for the database before starting the app". Handles platform linux/amd64, the private registry login, the healthcheck wait-until-ready, and a one-shot init service that creates appdb (the engine does not auto-create databases). Not the SQL Server image. Prefer this for any compose or Dev Container SQL wiring.

Writes integration tests that run IN CODE against a real Azure SQL Database container, spun up per test or per suite with Testcontainers and torn down after. Use when the user asks for "integration tests against SQL", "Testcontainers", "spin up a database for tests", "an ephemeral test database", "a test database per test", "xUnit/Jest/pytest with a real database", or "a database fixture". Use this INSTEAD of the Testcontainers MsSql preset (mcr.microsoft.com/mssql/server), because this is the Azure SQL engine (EngineEdition 5). For wiring the engine into a CI pipeline via service containers or workflow YAML instead, use azuresql-db-ci.

Sequences standing up a new application on Azure SQL Database and routes each decision to the skill that owns it. Use at the start of a project, when a user says "build an app on Azure SQL", "add Azure SQL Database to my app", "which stack should I use with Azure SQL", "where do I start", "generate an API over my database", or "get this into Azure without a password in the repo". It establishes the order that works: server-side prerequisites before any code, an identity instead of a password, schema through a migration not at startup, and a generated data API before hand-written CRUD. It routes rather than repeats: provision-azure-sql-db creates the database, connect-to-azure-sql drivers and retry, entra-id-auth the identity, dab-rest-and-graphql and azure-functions-sql-bindings the API layer, deploy-app-to-azure shipping, azuresql-db-scaffold the local container version.

Loads data into Azure SQL Database fast by choosing the right route: BULK INSERT and OPENROWSET(BULK ...) from Azure Blob Storage, bcp, .NET SqlBulkCopy, and the Python and Node.js bulk-copy equivalents. Use when someone says "bulk insert", "bulk load a CSV", "bcp in", "OPENROWSET BULK", "load a file into a table fast", "SqlBulkCopy", "fast_executemany", or pastes the error "OPENROWSET is not allowed to read local files" (Msg 12713) or a load stuck on a LOG_RATE_GOVERNOR wait. Covers choosing between the Blob-only server-side paths and the client-side paths, and the log rate cap that throttles every one of them regardless of logging mode. Does not design the target table (design-azure-sql-schema), establish the connection (connect-from-python, connect-from-dotnet, connect-from-typescript-and-node) or run a DACPAC or BACPAC export or import (sqlpackage-import-export).

Creates, starts, reads back and drops a database-scoped Extended Events session on Azure SQL Database, and names the ways one reports success while capturing nothing. Use when someone asks to capture query text, blocking or deadlocks with Extended Events, XEvents or an XE session on Azure SQL Database, pastes a session that ran without error and left an empty ring buffer, or has a session that never fires. Covers ON DATABASE scope and the error ON SERVER raises, the ring buffer shredded from XML into a rowset, the event_file target's need for a blob URL and a matching credential, the events and actions the service refuses, and the absence of a built-in system_health session. Does not diagnose slow queries, blocking or resource pressure once the data exists (diagnose-slow-query, diagnose-blocking-and-deadlocks, diagnose-resource-pressure) or read a plan (read-execution-plan).

Connects a .NET application to Azure SQL Database with Microsoft.Data.SqlClient: which package references are required, the encryption defaults and what changed, connection pooling and the keys that split a pool, and managed identity or other Microsoft Entra ID modes. Use when a user says "connect .NET to Azure SQL", "Microsoft.Data.SqlClient", "SqlConnection", "passwordless access for my .NET app", "managed identity for my API", "Active Directory Default", "Max Pool Size", "Encrypt=Strict", or asks whether "Microsoft.Data.SqlClient.Extensions.Azure" is needed. Also use when an app authenticates with a password locally and must use an identity in Azure. Covers packages, connection string keywords, pooling and Entra ID for .NET only; the ORM path is ef-core-azure-sql, and encryption doctrine plus transient-fault retry belong to connect-to-azure-sql.

Connects a Python application to Azure SQL Database, choosing between Microsoft's first-party mssql-python driver and the incumbent pyodbc, and covering driver installation, the connection string each one wants, connection pooling, and Microsoft Entra ID including token-based authentication. Use when a user says "connect Python to Azure SQL", "mssql-python", "pyodbc", "install the ODBC driver so my Python code can connect", "which Python driver for SQL Server", or hits errors such as "data source name not found and no default driver specified" or a container image that cannot load the driver. Also use when adding a database layer to a Python service, or when it needs a passwordless connection. Covers installation, connection strings, pooling and Entra ID for Python only. Encryption doctrine and transient-fault retry belong to connect-to-azure-sql; Node and .NET have their own skills.

Connects a TypeScript or JavaScript application to Azure SQL Database with the mssql package over tedious: which packages to install, where the connection pool has to live, how to type query results, and how to authenticate with Microsoft Entra ID without a password. Use when a user says "connect my Node app to Azure SQL", "which npm package for SQL Server", "mssql pool size", "passwordless connection from Node", "azure-active-directory-default", "@types/mssql", or reports that a Node API gets slower under load, opens a connection per request, or runs out of connections. Also use when adding a database layer to a Node backend, an Azure Function or an Express route. Covers driver installation, the config object, pool lifetime and Entra ID for this stack only. Encryption doctrine, retry and transient-fault handling belong to connect-to-azure-sql; Python and .NET have their own skills.

Connects an application to Azure SQL Database: picks the Microsoft driver for the language, sets encryption and certificate validation, sizes the pool against the worker limit not the session limit, and makes retry part of the first version of the code. Use when a user asks "how do I connect to Azure SQL", "which driver should I use", "what goes in the connection string", "add retry logic", "the connection keeps dropping", "should I set TrustServerCertificate", or "my app times out connecting to Azure". Also use when a first connection to a free or serverless database fails with error 40613, documented resume behaviour, not an outage. Azure SQL Database only, not Azure SQL Managed Instance and not self-managed SQL Server. Driver installation, connection strings and pooling per language belong to connect-from-dotnet, connect-from-python and connect-from-typescript-and-node.

Decides what a Data API builder configuration on Azure SQL Database actually publishes and to whom, at the version 2.0 model: entities generated from patterns, roles that inherit upward, row-filtering policies, relationships, and the passwordless connection a hosted run needs. Use when Data API builder is already in play and the question is about "autoentities", "dab auto-config", "my dab-config.json has hundreds of entities", "why can anonymous read this entity", "restrict which rows a caller can see", "add a relationship to my config", or moving a working configuration to Azure SQL Database with a managed identity. Also use when a configuration reviews cleanly but serves more of the database than the author asked for, the default include pattern plus the Unauthenticated provider dab init writes. Standing a first endpoint up belongs to azuresql-db-dab.

Takes a working local application and its Azure SQL Database to Azure with the Azure Developer CLI, reading its infrastructure rather than inheriting it. The one first-party template pairing a web app with Azure SQL Database uses a database password and grants db_owner, and the firewall rule it ships under an Azure services name spans the whole public address space. Use when a user says "deploy my app to Azure", "azd up", "which azd template should I start from", "get this into Azure without a password", or when a deployment reported success and the app then fails its first database call with a login failure. Covers what each template does about identity, what init, provision, deploy and up each do, and what teardown leaves behind. github-actions-for-sql owns pipelines, provision-azure-sql-db creating the server and database, entra-id-auth the database user and the grant.

Designs tables for Azure SQL Database so the first index or long value does not force a rebuild. Covers index key limits in bytes, why Unicode sizing makes NVARCHAR(850) and NVARCHAR(450) the real ceilings, collation decided once at CREATE DATABASE, the implicit conversion that turns a lookup into a scan, identity gaps of a thousand after a restart, unique columns that accept exactly one NULL. Use when creating or reviewing tables, porting a PostgreSQL or MySQL schema to Azure SQL Database, choosing a key, a string length or a collation, or reports a warning about maximum key length, an insert failing long after its migration, a lookup that suddenly scans, identity values that jumped, or a duplicate key on NULL. The engine rule under the mappers: ef-core-azure-sql and sqlalchemy-azure-sql own how each expresses it, t-sql-correctness syntax, vector-search-azure-sql vector columns.

Sets up local development from the Azure SQL Database dev container templates in microsoft/azuresql-devcontainers (.NET, .NET Aspire, Node.js, Python), each with a sample database and schema loaded. Use for "start from the Azure SQL Database dev container template", "which Azure SQL Database devcontainer should I pick", or "add a dev container with a database already in it", and for what these templates do: an empty database, a schema project that never deploys, a saved profile prompting for a password, a database at localhost not a service name, a vector index refused, a port on the app service refused, or the local database in a template not behaving the way the Azure SQL Database documentation describes, because it is SQL Server. Covers the SQL Database project whose target platform, not the engine, decides what Azure SQL Database accepts, and the create-time build and publish.

Finds who is blocking whom on Azure SQL Database right now, and reads a completed deadlock graph out of the database-scoped Extended Events session that captured it. Use when someone reports a query or app that hangs under load, pastes "Msg 1205" or "was deadlocked on lock resources", asks who is blocking a session, or ran a blocking query that came back empty and assumed nothing was blocked. Covers which grant a login needs to see another session's blocking and why that differs on Basic, S0, S1 and elastic pools, why an idle session holding a transaction is a head blocker that never appears in sys.dm_exec_requests, and how optimized locking's wait types differ. Does not tune an unblocked query (diagnose-slow-query), diagnose CPU, memory or IO pressure (diagnose-resource-pressure), build or repair the session (capture-with-extended-events) or read the plan (read-execution-plan).

Diagnoses an Azure SQL Database connection refused before a credential was evaluated, reading the error number to name the layer that refused: the IP firewall (40615), a virtual network rule (40914), public network access disabled (47073, 42101), the gateway declining a server name or login format (40532, 40531), a TLS version under the server minimum (47072), plus the transport, pre-login, timeout and certificate failures that carry no number. Use when someone pastes an error naming an IP address, a firewall, the gateway, a certificate chain, the pre-login handshake or a bare timeout, before anyone edits a connection string: none of these is a connection-string problem. Not what the server decided after reading the credential: a login refused, or a valid login with no database user, is entra-id-auth's; a database asking for a retry while it resumes is connect-to-azure-sql's.

Answers whether an Azure SQL Database is slow because of CPU, data or log IO, memory, or a worker and session limit. Use when someone reports the database as slow, throttled or timing out under load, pastes a resource governance error such as "the request limit for the database is 200 and has been reached" or a raw error number 10928, 10929 or 10936, asks whether to scale up the service tier, or is reading sys.dm_db_resource_stats, sys.dm_os_performance_counters or sys.dm_os_wait_stats. Covers the local Azure SQL Database container too. Does not read an execution plan (read-execution-plan), diagnose a blocking chain (diagnose-blocking-and-deadlocks), rewrite a slow query (diagnose-slow-query), resolve a connection failure (diagnose-connection-errors), size a connection pool (connect-to-azure-sql) or speed up a bulk load (bulk-load-and-bulk-copy).

Triages a slow Azure SQL Database query into one of four causes before anyone touches an index or a service tier: volatile, duration swings across executions; blocked, waiting on another session; regressed, a worse plan replaced a good one; or growing, duration rises with data volume. Reads Query Store runtime stats, plan history and per-plan waits, and knows where AUTO capture mode silently drops the query asked about. Use when a query "used to be fast" or runs inconsistently: "this took a second yesterday and ten today", "sometimes it's fast and sometimes it isn't", "did last night's deployment make this slower". Ends in a diagnosis, not a fix: CPU, memory, IO and tier go to diagnose-resource-pressure, blocking and deadlocks to diagnose-blocking-and-deadlocks, the plan itself to read-execution-plan, a query Query Store missed to capture-with-extended-events.

Configures Entity Framework Core against Azure SQL Database, where retry is on by default and redefines a transaction: the execution strategy refuses a user-initiated transaction, and the wrapper it tells you to write replays the whole unit, so a fault after the commit writes the row twice and reports success. Also covers UseAzureSql versus UseSqlServer, EnableRetryOnFailure, JSON mapping and split queries. Use when a DbContext targets Azure SQL Database, and for "EnableRetryOnFailure", "connection resiliency for EF Core", "UseAzureSql or UseSqlServer", "AsSplitQuery", an Include returning tens of thousands of rows, "does not support user-initiated transactions", duplicated rows after a retry, or a migration that retypes JSON columns. Not general EF Core: pooling is connect-from-dotnet, retry connect-to-azure-sql, identity entra-id-auth, a pipeline github-actions-for-sql.

Generates embeddings and chunks inside Azure SQL Database with CREATE EXTERNAL MODEL, AI_GENERATE_EMBEDDINGS, AI_GENERATE_CHUNKS and sp_invoke_external_rest_endpoint, covering the database scoped credential naming rule, the permissions, the dimension budget that decides which embedding model fits, and the outbound allowlist. Use when someone asks to "create an external model", "call AI_GENERATE_EMBEDDINGS", "embed text in T-SQL", "chunk text in the database", or "call an Azure OpenAI endpoint from SQL"; when such a call fails on the credential secret, managed identity, permissions, HTTPS or a blocked domain; and when embedding a whole table in one statement runs for hours. This skill owns producing the vector and calling out of the engine; storing and searching it is vector-search-azure-sql, the pipeline around it is rag-on-azure-sql, and offline embedding from application code is outside this in-engine workflow.

Takes an application identity to a passwordless connection to Azure SQL Database, and diagnoses it when that fails: sets the Microsoft Entra administrator, creates the database user for a managed identity or service principal, and grants roles. Use for "set up Microsoft Entra authentication for Azure SQL", "connect with a managed identity", "stop putting the database password in configuration", or "turn on Microsoft Entra-only authentication", and for the container once its MSSQL_AAD_ variables are set. Owns failures after a credential was evaluated: Msg 33134 "Principal could not be resolved", Msg 33131 "duplicate display name", 18456 "Login failed for user", 4060 "Cannot open database". What fails before that is diagnose-connection-errors; the connection code itself is connect-from-dotnet, connect-from-python or connect-from-typescript-and-node.

Ships schema changes to Azure SQL Database from a GitHub Actions workflow with azure/sql-action: building the database project or publishing a prebuilt dacpac, federating the workflow's token so no database password or client secret is stored, getting a runner with a changing address through the server firewall, and gating the deployment on an environment. Use when a user asks to "deploy my database project from GitHub Actions", "publish a dacpac on merge", "set up OIDC login to Azure for my pipeline", "stop storing a SQL password in secrets", or "require an approval before the schema deploys", and when a run fails with "no matching federated identity record found for presented assertion subject", a login error naming auth-type, or "unable to detect client IP address". sql-database-projects owns the project and publish options, entra-id-auth the database user and its grant.

Wires LangChain or LlamaIndex to Azure SQL Database from Python: the SQL toolkits, their text to SQL prompts, the langchain-sqlserver vector store, and the guardrails neither framework enforces. Use when someone asks to "use LangChain with Azure SQL", "build a SQL agent over the database", "text to SQL", "SQLDatabaseToolkit", "NLSQLTableQueryEngine", "which LlamaIndex vector store works with Azure SQL", or "make the SQL agent read only"; when a SQL agent keeps generating LIMIT, its query checker approves a query the database refuses, or its schema tool puts real rows into the prompt; or when a framework-created embedding table refuses CREATE VECTOR INDEX or a metadata filter throws arithmetic overflow. Vector type and query shape are vector-search-azure-sql, the cloud pipeline is rag-on-azure-sql, and drivers and token authentication are connect-from-python. Offline local embedding is an application-side workflow.

Handles SQL injection on Azure SQL Database beyond parameterisation: a typed sp_executesql parameter matches nothing where the same input concatenated into EXEC() returns every row; QUOTENAME returns NULL above 128 characters, so the batch built from it becomes NULL and does nothing; a dynamic ORDER BY built from one CASE over mixed types fails only for the sort key on the lower-precedence branch; dynamic SQL breaks the ownership chain, so EXECUTE AS decides what it may touch; and Always Encrypted refuses a literal (Msg 206). Use for a general injection question or a pre-production review, when a QUOTENAME-built statement returns and raises nothing, when a sort-by-column feature throws an operand type clash for one column only, when a procedure works until its query becomes dynamic, or when an encrypted column will not take a literal. Row level tenant isolation is rls-multi-tenant.

Uses Prisma ORM against Azure SQL Database on JavaScript and TypeScript, inside the connector's real limits: no Json type, no enums, no scalar lists, a default string length that quietly breaks keys, a connection URL that moved out of the schema file in Prisma 7, and a migration workflow that succeeds locally and is refused in the cloud. Use when a user says "Prisma with Azure SQL", "prisma migrate dev", "prisma db push", "schema.prisma", "prisma.config.ts", "driver adapter", or pastes "P3020", "the automatic creation of shadow databases is disabled", "the current connector does not support the Json type", or "the datasource property url is no longer supported". Also use when Prisma migrations work locally and fail against Azure. Covers schema, type mapping, migrations and identity for Prisma only. Drivers and pooling are connect-from-typescript-and-node, retry connect-to-azure-sql.

Creates an Azure SQL Database and returns a connection string that actually works, covering the free offer and paid tiers, the firewall rule, and Microsoft Entra-only administration. Use when a user asks to "create an Azure SQL database", "set up a free SQL database in Azure", "provision SQL for this app", "give me a connection string", or when an application needs a cloud database and none exists yet. Also use when a provisioning attempt succeeded but nothing can connect, which is almost always the missing firewall rule. Covers how many free databases a subscription actually gets and the exhaustion behavior value the CLI accepts, which is not the one its own help text describes.

Puts a real workload on the Hyperscale service tier of Azure SQL Database: when to choose it, how to size it, and how to convert an existing database without walking through a door that does not open again. Use when a user asks "should I use Hyperscale", "convert my database to Hyperscale", "we are close to the 4 TB ceiling", "how many vCores for Hyperscale", "Hyperscale serverless or provisioned", "add a read replica", "elastic pool for Hyperscale", or "can I go back from Hyperscale". Also use when a free offer database has to become a real one, because the free limit must be turned off before the tier can change and that step cannot be undone. Covers the eligibility rules for reverse migration, controlling the cutover, replica-based read scale-out, and what actually limits write throughput. Creating the server, the database and the firewall rule belongs to provision-azure-sql-db.

Answers whether a retrieval augmented generation prototype proved on the local Azure SQL Database container still holds in Azure SQL Database, and names what does not survive the move. Owns the offline loop, the local embedding model, and the parity claim. Use when someone asks to "prototype RAG offline with no cloud account", "use a local embedding model with SQL", "develop against the container and deploy to Azure SQL Database", or asks what has to be redone after the move; and when the engine refuses a local embedding endpoint, or a vector index and a security policy will not coexist. A plain request to build RAG on the container belongs to azuresql-db-rag; come here for the move. The cloud pipeline is rag-on-azure-sql, the type and the query vector-search-azure-sql, embedding in the engine embeddings-and-external-models, framework wiring langchain-and-llamaindex-on-azure-sql.

Builds retrieval augmented generation end to end on Azure SQL Database: chunking source text, storing embeddings with the provenance that makes them re-runnable, retrieving with the filter and the permission check inside the same query, and grounding an answer on what came back. Use when someone asks to "build RAG on Azure SQL Database", "chat with my documents", "add semantic search over my data", "keep embeddings in sync when rows change", "re-embed with a new model", or "which chunks should I put in the prompt"; and when a retrieval pipeline returns plausible but wrong context, or returns text the asking user is not allowed to read. This skill owns the pipeline and the schema around it. The vector type, VECTOR_DISTANCE and the query shape are vector-search-azure-sql, and the in-database embedding call is embeddings-and-external-models. Offline local embedding is an application-side workflow.

Retrieves an Azure SQL Database execution plan, estimated or actual, and pulls out the small set of facts that explain slowness: operators, estimated versus actual row counts, warnings, missing-index hints, and the memory grant, instead of returning the whole plan XML. Use when someone says "read this execution plan", "why did the optimizer choose a scan here", "show me the actual plan not the estimated one", or hands over a plan and asks what is wrong with it. Also covers retrieval itself: SET SHOWPLAN_XML, SET STATISTICS XML, the plan-handle views, and Query Store, and the several ways a same-looking call returns the wrong kind of plan, a stub, or NULL without raising an error. Not general slow-query triage (diagnose-slow-query), lock analysis (diagnose-blocking-and-deadlocks), or instance-level CPU or memory pressure (diagnose-resource-pressure).

Recovers an Azure SQL Database after data loss, an accidental drop or a bad deployment, using point-in-time restore, geo-restore and long-term retention. Use when someone asks to "restore my Azure SQL database", "undo a dropped table or database", "roll back to before this migration ran", "recover from a region outage", or asks for RESTORE DATABASE or BACKUP DATABASE syntax. There is no backup or restore T-SQL here: BACKUP DATABASE, RESTORE DATABASE and every RESTORE ... ONLY variant are refused, and restoring is a control plane operation. Every restore creates a new database beside the one being recovered rather than overwriting it, so this covers the restore type and the rename or connection swap back. Not a schema rollback (schema-migrations-safely), not a logical export or import (sqlpackage-import-export), not creating it (provision-azure-sql-db).

Builds tenant isolation on Azure SQL Database that a test can prove, with a row level security policy whose filter predicate and block predicate are written together, because a filter alone still accepts a cross-tenant write and hides the row from the app that made it. Use when asked to add row level security, isolate tenants in a shared table, write a security policy or predicate function, set the current tenant through SESSION_CONTEXT or a database user per tenant, or prove one tenant cannot read another; and when a multi-tenant app returns the wrong tenant's rows under load, retrieval returns another tenant's chunk, a policy is in place and all rows are still visible, or error 33504 appears on an insert or update. Covers pooling against a session-scoped tenant id, who can turn a policy off, and the isolation test. Identity is entra-id-auth, the table design design-azure-sql-schema.

Decides whether a schema change is safe to apply to a live Azure SQL Database, and rewrites the migration so it is. Use when someone asks "is this migration safe to run in production", "can I add this column without downtime", "zero downtime schema change", "expand and contract", "blue green database deploy", "make this migration re-runnable", "should the app run migrations at startup", or "how do I roll this back"; and when a deployment blocked every query, instances fought over the same migration, or a retry applied its backfill twice. Covers metadata-only versus table-rewriting alterations, the schema lock that blocks readers under snapshot isolation, ONLINE and RESUMABLE, and why a guard is not a guard under concurrency or retry. Tooling is sql-database-projects and github-actions-for-sql, ORM migrations their own skills, the table design design-azure-sql-schema.

Turns a defect in a Microsoft SQL agent skill, plugin, or marketplace into a redacted, prefilled GitHub issue the user reviews and submits. Use when a skill gave wrong or missing instructions, the wrong skill fired or none did, a skill would not install, or a description or routing in the marketplace is wrong; also when the agent worked around a defect in the skill it was following even though the task succeeded. Triggers on "file a bug", "report this", "open an issue", "give feedback on this skill". Not for an ordinary Azure SQL Database or T-SQL failure where the skill's guidance was correct and only the service or the query is misbehaving; that belongs to the skill owning the topic, such as diagnose-connection-errors. Strips connection strings, passwords, tokens, server names, subscription and tenant ids and email addresses, and never submits without confirmation.

Builds and publishes a SQL database project against Azure SQL Database: the SDK-style .sqlproj on Microsoft.Build.Sql, the target platform that decides what the build actually validates, pre and post deployment scripts, the refactorlog, and code analysis. Use when a user asks to "create a SQL database project", "build a dacpac", "publish a dacpac to Azure SQL", "add a post-deployment script", "rename a column without losing its data", or "turn on code analysis", and reports "the build passed but the publish failed", "the deploy said success and the data is gone", or "the post-deployment script failed and the table already changed". Covers what dotnet build does not check, what SqlPackage does with a mismatched target platform, and which publish options change data rather than schema. github-actions-for-sql owns the pipeline, schema-migrations-safely the change doctrine.

Uses SQLAlchemy correctly against Azure SQL Database, where the dialect appends an OUTPUT clause to INSERT statements and that single clause explains two failures agents never connect: a hard error on any table carrying a trigger, and fast_executemany appearing to do nothing. Use when a user says "SQLAlchemy with Azure SQL", "mssql+pyodbc", "implicit_returning", "fast_executemany", "insertmanyvalues", "Alembic against Azure SQL", or pastes "the target table of the DML statement cannot have any enabled triggers if the statement contains an OUTPUT clause without INTO clause". Also use when an ORM insert fails on one table only, or a bulk load is no faster after fast_executemany was set. Covers the engine URL, the generated DML, type mapping and Alembic. Driver choice is connect-from-python and retry connect-to-azure-sql.

Moves a whole Azure SQL Database as a portable file with SqlPackage, choosing between the Extract, Publish, Export and Import actions, stating what each one carries, and giving the command line for each. Use when asked to export a database to a bacpac, extract or publish a dacpac, clone or move a database between servers, move the database itself from the local Azure SQL Database container up to Azure SQL Database, explain dacpac versus bacpac, or diagnose a failed sqlpackage run such as SQL71627, or SQL71659 when an Import stops because the target database is not empty. Application connection changes and first-time local-container setup are separate workflows.

Writes T-SQL that returns the right answer on Azure SQL Database, and catches statements that return a wrong answer with no error: NULL compared using = or <> or NOT IN, ISNULL and COALESCE differing in return type, integer division truncating, a string variable declared with no length, and a session where QUOTED_IDENTIFIER is OFF. Also corrects PostgreSQL and MySQL habit (LIMIT, RETURNING, SERIAL, ILIKE, NOW(), true, false, double-quoted literals, TEXT columns, ON CONFLICT, USE) and the opposite mistake of avoiding syntax supported since 2025. Use when writing, porting or reviewing SQL, and for "why is that row missing", "why did NOT IN return nothing", "why is this average wrong", "how do I paginate", "how do I get the id I just inserted", "is this comparison case sensitive". Upserts are t-sql-upserts-merge, JSON t-sql-json-and-openjson, table design design-azure-sql-schema.

Queries and stores JSON on Azure SQL Database using the native json type, a JSON index, and OPENJSON with an explicit WITH schema, instead of the older nvarchar(max) plus JSON_VALUE pattern the training data is full of. Use when asked to "store JSON in SQL", "query a JSON column", "shred a JSON array into rows", "flatten this payload into a table", "index a JSON property", "should this be nvarchar(max) or the json type", "parse the API response we saved", or when JSON_VALUE, JSON_QUERY, JSON_MODIFY, ISJSON, OPENJSON, JSON_OBJECT or JSON_ARRAYAGG appears in a query being written or reviewed; and when a JSON lookup returns NULL for a value that is visibly present, or invalid JSON reached a column that nothing rejected. Where a document column belongs in a table design is design-azure-sql-schema, and general T-SQL dialect is t-sql-correctness.

Writes an upsert for Azure SQL Database that is still correct when two sessions run it at the same moment, and refuses the MERGE shapes that lose rows. Use when asked to "insert or update", "insert if not exists", "add or update", "make this insert idempotent", "upsert", "write a MERGE", "sync a staging table into the target table", make a row-by-row load or import safe to run twice, or port ON CONFLICT DO UPDATE or ON DUPLICATE KEY UPDATE; and use when duplicate rows appear that nothing in the application created, or when error 2627, 2601, 8672, 10713 or a deadlock shows up under load. Covers why IF EXISTS then UPDATE ELSE INSERT is a race, what MERGE needs to be safe, which MERGE shapes to refuse outright, and the two patterns that are safe without MERGE. Key and index design belongs to design-azure-sql-schema, and general T-SQL dialect to t-sql-correctness.

Stores and searches vectors natively in Azure SQL Database: the vector type, VECTOR_DISTANCE, the 1998 dimension ceiling, the DiskANN vector index, and the long list of places a vector column is refused. Use when a schema needs an embedding column, when someone asks to "store embeddings in SQL", "do similarity search", "cosine distance", "top k nearest neighbours", "CREATE VECTOR INDEX", "VECTOR_SEARCH" or "WITH APPROXIMATE"; when a vector column is rejected as a key, a constraint, a computed column or inside ORDER BY, GROUP BY, DISTINCT or UNION; and when a similarity query returns the right rows but scans the whole table. This skill owns the type and the query surface. The end to end pipeline is rag-on-azure-sql, generating embeddings embeddings-and-external-models, and a vector column's place in a wider design design-azure-sql-schema.