Microsoft SQL Apps: Build a Database-Backed App With Any AI Assistant

Microsoft has published a new open-source repository, microsoft/sql-apps, that aims to let someone with an idea, and an AI coding assistant of their choice, get to a working database-backed web app without first choosing a framework. The repo is brand new (it appeared on GitHub's trending list in the week of October 9, 2026) and is MIT licensed. At the time of writing it has six commits and no stars, so this is a day-zero look at what Microsoft says it is, not a verdict on how well it works.

In short: SQL Apps is a foundation plus a set of guides. You open the project in your editor, point your assistant at the files, describe the app, and the assistant implements screens and SQL behavior on top of the foundation. The README is explicit that this is "not a one-command generator."

TL;DR: what you need to know

What does SQL Apps actually give you?

The README frames the pitch as "Start free. Build something real. Make it yours." The journey it describes has four steps: Describe, Run locally, Make it yours, Share optionally.

The suggested projects are deliberately small and ordinary: an equipment checkout app that records loans and returns, an inventory app, a registration app that collects signups, or a small team workflow with records, file uploads or background file processing. These are ideas rather than templates. The only concrete example included is a separate to-do list reference app, and the default foundation ships with no to-do screen and no sample data.

The README gives a sample first prompt: ask the assistant to help build an equipment checkout app, start by asking who will use it and what it should do, run it locally, make one useful change, and not deploy yet. That "ask me one question at a time" pattern is repeated in the Build your app guide, which walks through scoping the first version (people, information, actions, one first improvement), implementing it, creating a test record and reloading to confirm persistence, and then making a change such as a due date with an overdue filter.

A small npm run guide command saves the agreed app description and a suggested next step, so a later session, or a different assistant, can pick up where the last one stopped. That is a practical answer to the problem every AI-assisted build hits: the assistant forgets the plan between sessions.

Database cylinder stack illustration for the Azure SQL foundation behind Microsoft SQL Apps

How does the local setup work?

Local-first is the headline design choice. According to the README, you need Node 22 or 24, a .NET SDK, Docker with Linux containers, and access to the Azure SQL Database container. Initial package and image downloads need internet. A node scripts/setup-check.mjs command explains missing prerequisites without installing anything.

The catch is the container. Microsoft's Azure SQL Database container page describes it as the Azure SQL Database engine itself running locally for development, "Free for local development and CI," with no Azure subscription or credit card, and a promise of under a minute from docker pull to first query. It lists compatibility with drivers such as node-mssql, mssql-python, pyodbc and mssql-jdbc, and ORMs including Prisma, SQLAlchemy, EF Core, Django and TypeORM. But the page is labelled Private Preview, and the SQL Apps README tells you to request access. Until you are admitted, the local path is blocked, which is the single biggest practical limit today.

The reason this matters is the pitch of "cloud parity": develop against the same engine you will use in Azure, so the move from your laptop to production does not involve rewriting connection strings or adapting to a different database flavor.

Which assistants does it work with?

The README says the guides and commands do not require a particular provider. If you use GitHub Copilot, an optional plugin adds project-specific skills. The repository file listing shows plugin folders for several tools, including Claude, Codex, Cursor, Grok and Kimi, alongside an agents folder. We have not tested each one, so treat that as evidence of intent rather than a compatibility guarantee.

This provider-neutral stance fits a wider pattern. Microsoft has been pushing local and hybrid AI on Windows, as in our coverage of Windows hybrid intelligence and local-cloud agents and the MAI-Code-1.1-Flash model for local Copilot use. SQL Apps sits at a different layer, the app and data foundation rather than the model, but it targets the same developer who wants to work on their own machine first.

What does it cost to share an app?

The costs guide is unusually blunt, which is worth quoting in spirit. Running SQL Apps on your computer does not create an Azure usage bill, though Docker Desktop and your AI provider have their own terms and pricing. Azure is the cloud target for sharing.

The guide says free tier means recurring monthly allowances, "not a time-bound trial," and warns of several details:

• Azure SQL and Container Apps have free allowances, but the current demo templates also use a paid container registry and managed networking. Scaling the app to zero does not remove those charges.
• The authenticated deployment uses additional paid services.
• The free-tier SQL configuration pauses at its monthly limit rather than switching to paid usage, so the app can be unavailable until the next calendar month. Idle pause and resume can also add delays.
• Budget alerts notify you but do not stop spending.
• SQL Apps does not currently provide a guaranteed zero-cost deployment. If zero spending is a requirement, the guide says to stay local.

It also notes that public visitor-session creation has no app-level admission throttle or active-session cap, and that automated traffic consumes resources too. For growth, it points to Database Hub in Microsoft Fabric (preview), available with a Fabric Free license, to monitor usage before deciding to pay for capacity.

Free tier gift box beside a meter illustrating Azure SQL Apps recurring monthly allowances

How is this different from other AI app builders?

Hosted builders generate and host an app in their own environment. SQL Apps is closer to a starter kit that lives in your repo: the code, schema and guides are files on your disk, edited by whichever agent you trust, with Azure as an optional deployment target. The trade-off is more setup (Docker, .NET, Node, a private-preview container) in exchange for local control and an engine that matches production.

Other tools in our corpus take different positions on the same idea. Zite's MCP-based team apps put the builder in a hosted product; Microsoft's Copilot home, code and autopilot relaunch shows the company's own assistant strategy. SQL Apps does not compete with either directly, it supplies the data layer and conventions that an assistant can build against.

Who is this for, and who should wait?

It looks well suited to people who can already read SQL or a bit of TypeScript and want a sanctioned structure for a small internal tool: equipment loans, inventory, signups. The guides also invite non-SQL users to describe their data in everyday language and let the assistant propose tables.

You should probably wait if you need production hosting today, cannot get into the container preview, cannot run Docker with Linux containers, or need a firm zero-cost guarantee. The README itself says the minimal public-demo deployment workflow is not yet complete, and that local success does not imply readiness for public or production use.

Safety questions to ask before you let an agent near your data

An assistant that writes SQL and API code can also write mistakes. The guides recommend synthetic test data while developing, checking who can see or edit a record if the app has different users, and reviewing the changes the assistant makes. We would add a few habits:

1. Keep real personal data out of the first version, and review every migration the assistant generates before applying it.
2. Check that required-field validation and permissions are tested, not just present.
3. Run the assistant with the narrowest file and network access you can.
4. Decide up front what the assistant may do without asking, such as dropping tables or deploying.

For teams giving coding agents wider reach, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions. Reliability of agents that touch databases is also the subject of Microsoft's ThinkingBox benchmark on database state, which is worth reading before you trust an agent with schema changes.

Local LLM home machine illustration for running SQL Apps and an AI assistant on your own computer

Try it: a first session

If you have container access, a reasonable first session looks like this:

git clone https://github.com/microsoft/sql-apps
cd sql-apps
node scripts/setup-check.mjs

Open the folder in your editor, give your assistant the project files, and use the README's prompt: ask it to help build your idea, to ask one question at a time, to run the app locally, and to make one useful change without deploying. Create a record, reload, add a field, and run npm run guide to save the plan. Only then read the sharing and cost guides.

What to watch next

Early signals to track: how fast the private preview of the container opens up, whether the deployment workflow for public demos is finished, whether the plugin folders for non-Copilot tools get real documentation, and how the repo's early contributions develop (it had one open pull request when we looked). We will add an update here if Microsoft announces availability changes.

Related reading

• Windows hybrid intelligence and local-cloud agents
• MAI-Code-1.1-Flash for local Copilot
• Microsoft Copilot home, code and autopilot relaunch
• Zite MCP team apps
• Microsoft ThinkingBox benchmark: database state reliability
• GitHub Copilot runtime Rust migration

Sources: microsoft/sql-apps README and docs, Azure SQL Database container preview page.

Repository details are accurate as of October 9, 2026 and are likely to change quickly.