Big news: Azure SQL Developer is here, in private preview. It's the 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 you're in 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. The inner-loop problemIf 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 SQL, on your laptop.Meet Azure SQL Developer 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. Why this lands Same engine, local and cloud. Your T-SQL, migrations, and driver behavior carry straight through to Azure. Free for local dev and CI. No subscription, no shared instance, no credit card. Your stack, unchanged. node-mssql, mssql-python, pyodbc, and mssql-jdbc all work, and so do Prisma, SQLAlchemy, EF Core, Django, and TypeORM. AI-ready, like the cloud. Native VECTOR type, VECTOR_DISTANCE, AI_GENERATE_EMBEDDINGS, and CREATE EXTERNAL MODEL. Prototype RAG with a local model, then switch to Azure OpenAI (DiskANN indexes are in development). Works offline. After the first pull, it runs with no internet, perfect for demos, classrooms, and workshops. 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 youPath 1: Do it by handSign up and sign in to the registrySign up for the preview 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.docker login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io -u Start the containerdocker run pulls the image on first use, so one command takes you from signed-in to running: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[alert type="important" heading="On a non-x64 host (Apple Silicon)?"]add --platform linux/amd64 to the docker run command above so the x64 image runs under emulation.[/alert]Replace YourStr0ng_Passw0rd 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".Create your app databaseCreate your app database. The engine does not auto-create them, matching Azure SQL Database:sqlcmd -S localhost,1433 -U sa -C -Q "IF DB_ID('appdb') IS NULL CREATE DATABASE appdb;"[alert type="tip" heading="No sqlcmd installed on your host?"]The container bundles it. Use docker exec sqldb /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -C -Q "..." instead.[/alert]Run your app locally against the container 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:SQL_CONNECTION_STRING="Server=localhost,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true"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.Deploy to Azure When you are ready to ship, the app does not change; only the connection string does. Here are the two, side by side:# Local (inner loop)SQL_CONNECTION_STRING=Server=localhost,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true# Azure (production)SQL_CONNECTION_STRING=Server=app.database.windows.net;Database=appdb;Authentication=Active Directory DefaultThe 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.Path 2: Let your AI agent do itBring 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.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:npx skills add microsoft/azure-sql-database-containerWorks across GitHub Copilot (VS Code and CLI), Claude Code, Codex, and Cursor.Then ask in plain English, for example: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 connects.Two skills worth calling out: azuresql-db-local-to-cloud turns Path 1's story into an agent workflow: run against Azure SQL Developer locally, deploy the same code to Azure SQL Database in the cloud with just the connection string swap. No code changes, no porting exercise. azuresql-db-faq and azuresql-db-feedback teach the agent what the engine can and cannot do (no PaaS-only surprises), and let it draft a prefilled bug or feature request for you to review. Nothing gets filed without your say-so.[alert type="note" heading="See the full skills catalog"]From bootstrap scaffolds to CI recipes to RAG on the native VECTOR type, at aka.ms/azuresql-developer-skills.[/alert]What you can build with the Azure SQL Developer Azure-faithful local dev: develop and test at local-disk speed, then deploy the same code to Azure. Lift-and-shift is a connection-string change. AI and RAG prototypes: build vector search and embeddings against a local database with a local model like Ollama, then switch to Azure OpenAI in the cloud, with no cloud spend while you experiment. Real integration tests in CI: spin the container up as a service in GitHub Actions or Azure Pipelines for true end-to-end tests, with no subscription and no shared-instance flakiness. Drop-in sidecar: add SQL Database to a docker compose stack or Dev Container, wire-compatible with the drivers and ORMs you already use. New project scaffolding: start a .NET Aspire, FastAPI, Next.js, or NestJS project with Azure SQL Database as the default local development resource. Offline workshops and demos: after the first pull, the container runs fully offline on a laptop.Get involvedThis is the Azure SQL Database engine, running on your laptop. Build, test, and ship against the real engine, with no Azure subscription, no shared instance, and no connection-string rewrites from inner loop to production. You shape this preview: try it, then tell us what you build and what breaks.Here's how you can contribute: 📝 Sign up for the Private Preview – Get your registry credentials and join the cohort. 💬 GitHub Discussions – Share ideas, ask questions, show what you built. ✨ Request a feature – Tell us what should ship next. 🐞 Report a bug – Help us fix rough edges early.Want to go deeper? 🎬 Watch the demo – The end-to-end loop in 90 seconds. 🛠️ Build something – Ready-to-copy prompts for local-to-cloud, RAG, CI, sidecar, and more. 🤖 Try the skills – The full agent skills catalog for Claude Code, GitHub Copilot, Codex, and Cursor.Thanks for being part of the journey. Happy building! 🚀