{"id":7253,"date":"2026-07-23T08:00:27","date_gmt":"2026-07-23T15:00:27","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/azure-sql\/?p=7253"},"modified":"2026-07-22T15:47:02","modified_gmt":"2026-07-22T22:47:02","slug":"azure-sql-developer-prpr","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/azure-sql\/azure-sql-developer-prpr\/","title":{"rendered":"Build locally, ship to Azure: meet Azure SQL Developer"},"content":{"rendered":"

Big news:<\/strong> Azure SQL Developer is here, in private preview. <\/span>It’s<\/span>\u00a0the Azure SQL Database engine, on your laptop, in a container. Build against the exact engine you run in the cloud. Ship the same code to Azure. Change one line, the connection string, and\u00a0<\/span>you’re<\/span>\u00a0in production. Free for local dev and CI. No subscription. No credit card. No catch. Run it yourself, or hand it to an AI agent and watch it go.<\/span><\/span>\u00a0<\/span><\/p>\n

The inner-loop problem<\/h3>\n

If you build apps on a cloud database, you know the friction. To develop and test locally, you either point your app at a shared cloud instance, with slow round trips, noisy neighbors, and connection-string rewrites between dev and prod, or you develop against a different database locally and hope the behavior matches once you deploy. Either way you pay a tax: cloud spend while you experiment, flaky integration tests, and the occasional “it worked on my machine” surprise when a local-only feature does not exist in the cloud. The fix is not a database that is like Azure SQL. It is Azure\u00a0SQL,\u00a0on your laptop.<\/p>\n

Meet Azure SQL Developer<\/span><\/b>\u00a0<\/span><\/h3>\n

This is the Azure SQL Database engine itself, in a container, on your machine. Not a clone. Not the SQL Server image. The same engine that runs Azure SQL in the cloud, with the same defaults, the same T-SQL, the same system views, the same error messages. <\/span>\u00a0<\/span><\/p>\n

Why\u00a0this lands<\/span><\/b><\/h3>\n
    \n
  1. Same engine,\u00a0local\u00a0and cloud. Your T-SQL, migrations, and driver behavior carry straight through to Azure.<\/span><\/li>\n
  2. Free for local dev and CI. No subscription, no shared instance, no credit card.<\/span>\u00a0<\/span><\/li>\n
  3. Your stack, unchanged. node-mssql,\u00a0mssql-python,\u00a0pyodbc, and\u00a0mssql-jdbc\u00a0all work, and so do Prisma,\u00a0SQLAlchemy, EF Core, Django, and\u00a0TypeORM.<\/span>\u00a0<\/span><\/li>\n
  4. AI-ready, like the\u00a0cloud. Native VECTOR<\/span> type, VECTOR_DISTANCE<\/span>, AI_GENERATE_EMBEDDINGS<\/span>, and CREATE EXTERNAL MODEL<\/span>. Prototype RAG with a local model, then switch to Azure OpenAI (DiskANN\u00a0indexes are in development).<\/span>\u00a0<\/span><\/li>\n
  5. Works offline. After the first pull, it runs with no internet, perfect for demos, classrooms, and workshops.<\/span>\u00a0<\/span><\/li>\n<\/ol>\n

    Now the full loop: start the container, run your app, ship to Azure. Twice. First by hand, then with an AI agent doing it for you<\/span><\/p>\n

    Path 1: Do it by hand<\/h3>\n

    Sign up and sign in to the registry<\/h4>\n

    Sign up for the preview<\/a> to get the registry username and password. They are pull-only, shared across the cohort, must be treated as secrets, and may be rotated during the preview.<\/p>\n

    docker login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io -u <username><\/span><\/code><\/pre>\n
    Start the container<\/h4>\n
    docker run<\/code> pulls the image on first use, so one command takes you from signed-in to running:<\/p>\n
    \n
    docker run --name sqldb -e \"ACCEPT_EULA=Y\" -e \"MSSQL_SA_PASSWORD=YourStr0ng_Passw0rd\" -p 1433:1433 -d sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io\/azure-sql\/db-dev:latest<\/code><\/pre>\n
    <\/i>On a non-x64 host (Apple Silicon)?<\/strong><\/p>add <\/span>--platform linux\/amd64<\/code> to the <\/span>docker run<\/code> command above so the x64 image runs under emulation.<\/div><\/span><\/pre>\n<\/div>\n
    Replace YourStr0ng_Passw0rd<\/code> with your own. The container enforces the default SQL password complexity policy: at least 8 characters, with a mix of upper case, lower case, digits, and symbols. Confirm the container is running with docker ps --filter \"name=sqldb\"<\/code>.<\/p>\n
    Create your app database<\/h4>\n
    Create your app database. The engine does not auto-create them, matching Azure SQL Database:<\/p>\n
    sqlcmd -S localhost,1433 -U sa -C -Q \"IF DB_ID('appdb') IS NULL CREATE DATABASE appdb;\"<\/code><\/pre>\n
    <\/i>No sqlcmd installed on your host?<\/strong><\/p>The container bundles it. Use docker exec sqldb \/opt\/mssql-tools18\/bin\/sqlcmd -S localhost -U sa -C -Q “…” instead.<\/div><\/p>\n
    Run your app locally against the container\u00a0<\/strong><\/h4>\n
    Your app reads its connection string from a single environment variable, SQL_CONNECTION_STRING. Point it at the local container and run your app exactly as you normally would:<\/p>\n
    SQL_CONNECTION_STRING=\"Server=localhost,1433;Database=appdb;User\u00a0Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true\"<\/code><\/pre>\n
    Run your migrations with EF Core, Prisma, Alembic, or SqlPackage, seed your data, and develop at local-disk speed, with no cloud round trip and no cloud spend.<\/p>\n
    Deploy to Azure\u00a0<\/strong><\/h4>\n
    When you are ready to ship, the app does not change; only the connection string does. Here are the two, side by side:<\/p>\n
    # Local (inner loop)\r\nSQL_CONNECTION_STRING=Server=localhost,1433;Database=appdb;User\u00a0Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true<\/code><\/pre>\n
    # Azure (production)\r\nSQL_CONNECTION_STRING=Server=app.database.windows.net;Database=appdb;Authentication=Active Directory Default<\/code><\/pre>\n
    The server is all that changes. Because it is the same engine, parity is the default, not a porting exercise. Point the connection at Azure SQL Database in the cloud and deploy the same app, without touching your code.<\/p>\n
    Path 2: Let your AI agent do it<\/h3>\n
    Bring your AI coding agent. Point it at Azure SQL Developer and let it scaffold the schema, write the migrations, and build the data layer against a real local database.<\/p>\n
    The repo ships a curated collection of agent skills: small, on-demand instructions that teach any modern agent to use the engine correctly, so it does not reach for the SQL Server image or invent behavior the engine does not have. Install once:<\/p>\n
    npx\u00a0skills add microsoft\/azure-sql-database-container<\/code><\/pre>\n
    Works across GitHub Copilot<\/strong> (VS Code and CLI), Claude Code<\/strong>, Codex<\/strong>, and Cursor<\/strong>.<\/p>\n
    Then ask in plain English, for example:<\/p>\n
    \n
    Get my Node.js + Sequelize app running against Azure SQL Developer locally: start the container, create the database, apply my migrations, and confirm npm run dev<\/code> connects.<\/p><\/blockquote>\n<\/div>\n
    Two skills worth calling out:<\/p>\n