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 problem

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 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

1. Same engine, local and cloud. Your T-SQL, migrations, and driver behavior carry straight through to Azure.
2. Free for local dev and CI. No subscription, no shared instance, no credit card. 
3. Your stack, unchanged. node-mssql, mssql-python, pyodbc, and mssql-jdbc all work, and so do Prisma, SQLAlchemy, EF Core, Django, and TypeORM. 
4. 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). 
5. 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 you

Path 1: Do it by hand

Sign up and sign in to the registry

Sign 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 <username>

Start the container

docker 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

On a non-x64 host (Apple Silicon)?
add --platform linux/amd64 to the docker run command above so the x64 image runs under emulation.

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 database

Create 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;"

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 Default

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.

Path 2: Let your AI agent do it

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.

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-container

Works across GitHub Copilot (VS Code and CLI), Claude Code, Codex, and Cursor.

Then ask in plain English, for example:

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.

What you can build with the Azure SQL Developer

1. 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.
2. 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.
3. 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.
4. Drop-in sidecar: add SQL Database to a docker compose stack or Dev Container, wire-compatible with the drivers and ORMs you already use.
5. New project scaffolding: start a .NET Aspire, FastAPI, Next.js, or NestJS project with Azure SQL Database as the default local development resource.
6. Offline workshops and demos: after the first pull, the container runs fully offline on a laptop.

Get involved

This 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!

The post Build locally, ship to Azure: meet Azure SQL Developer appeared first on Azure SQL Dev Corner.

Learn T-SQL With Erik: Don’t Be Slack With Data Types

Chapters

• 00:00:00 – Introduction to Data Type Mismatch Issues
• 00:02:45 – Using Date Functions with Incorrect Data Types
• 00:06:27 – Plan Shape Catastrophe Example
• 00:10:38 – Martin Smith’s VARCAR50 Demo
• 00:11:29 – Conclusion and Next Steps

Full Transcript

Erik, big deal darling here with Darling Data and today’s video we are going to talk about how you should not be slack with data types and by that I mean you should always very carefully match your data types. It can be important both for performance and logical correctness when you write your queries to do this. And we are going to look at some examples around date time and date time 2 and stuff like that.

So with that out of the way, if you like this material, it is available as a whole video course and there is a link down in the video description where you can pick it up today at this very second. It is just available to you for $100 off down below. There are also other helpful links there if you would like to engage with me in other ways.

You can hire me for consulting. You can become a supporting member of the channel for $4 to $10 a month. It is a heck of a way to say, here is a little tip jar.

Say, thanks Erik for all the free stuff. You can ask me office hours questions. Keep that gravy train rolling. And of course, I always do appreciate as the channel grows. So if you would not mind doing some level of liking, subscribing, and telling a friend, I would be momentarily grateful for you.

Not eternally. Just… Just a couple of seconds.

Hey, look, the number went up. That is cool. Back to work. If you would like a free SQL Server performance monitoring tool, I have got one. I have been working on it for, oh, I guess, six, seven months now.

So things are maturing pretty nicely. Certainly competitive with all the paid T-SQL, SQL Server monitoring tools out there in the world. And of course, the price tag on mine is way better.

So, you know, if you are curious, you can go download it and start testing it out. And of course, if you run into any issues, have any questions, have ideas that you would like to see in the monitoring tool, just throw them up on GitHub. And my robot companions and I will respond just as quickly as we can.

They do not sleep, but I do. But anyway, let us continue our voyage through the allergic environment. Let us continue our voyage through the allergic heat death hell of June.

And I have got the ACs blaring, absolutely blaring. That is why I am not shiny. All right.

So I have created an index here on the creation date column in the comments table in the Stack Overflow database. And we are going to look at the difference in performance when we are slack with data types versus when we are not. So this is the current sort of method that you would use to flatten dates.

And notice that it, like, so I have to do a little bit of extra work here because I am just using, like, passed in string values. If you were using, like, if you are writing strings, you know, you have to, you should be careful about making sure that your strings are unambiguous and formatted in a way that the SQL Server does not have, there is no guesswork about them. Make sure that we are using the style.

Of convert that we need. 112 for dates. I think it is 121 for date time, date time 2 and stuff like that.

So make sure that you are doing these things because, or sorry, 112. That 112, that 121. There we go.

For that. So we want to make sure that we are doing these things because they help SQL Server make the best possible choices. And they help you from running into weird issues with ambiguous data. If you ever have to internationalize your audience, you will find very quickly that dates become a very murky subject.

And I am not just talking about time zones, but we will talk about time zones later. You have got that to look forward to. Woohoo.

High five. Time zones. Nothing better. Yeah. But using this method of date flattening and converting specifically to date times, we get a nice, tidy, easy seek into our index on the comments table. And all is fairly well with this query.

Now, like I said in the last video, date trunk returns a dynamic data type. So if we do not convert this from what is obviously a date time 2 based on the number of milliseconds that we have here, SQL Server will return it as a date time 2. And when we start comparing date time 2s to date time columns, the performance does get a little bit worse here.

This isn’t like the end of the world. But notice that this plan does look a little funny. All right.

It is a constant scan. We have got a compute scalar. And then we go into a nested loops join this many times to go find the rows that we care about. This is because we are being slack with our data types. We lose that nice, tidy seek plan and we get this plan with all this extra stuff to it.

We are essentially creating a row set and joining that over and over again. That is not fun. That is not the kind of execution plan you want to see.

But if we are taking a look at the data types, we get a nice, tidy, easy plan. We are taking advantage of SQL Server 2022. Like brand-new SQL Server 2025. I am actually using 2025 at this point.

I think it is finally enough cumulative updates in where I feel pretty safe running demos and everything on it. But if we run this, what we are going to hit is, of course, or rather if we run this, we will see we will go back to our nice, tidy seek plan because we are converting to a date time up here. Duh.

Date time. Good for us. And we can at least get back to the seek plan that we wanted before. So that is exactly what we want to see. Similar caution does need to be shown when assembling a date time or date time to from parts.

You have a variety of functions at your disposal to assemble a date from parts. You have date from parts, date time from parts, and date time to from parts. And if you are just throwing some strings into those, things can get rather perilous for your queries.

Just a couple of examples here. If I run these, this is the first one that is using date from parts. And we are back to this sort of weird plan with the constant scan compute scaleR and the nested loops join over to here.

I mean, it takes like 300 milliseconds, which again, this is not the end of the world. This is not supposed to show you a drastic performance change. But it is there to show you the plan shape and what you want to look out for in your queries when you want to get things right.

Notice down here, when we use date time from parts, we are back to our simple seek plan. We get a parallel plan from this, which is good given the number of rows that we are hitting. You can sometimes get parallelism with these, but the optimizer support for it is not so great.

But one thing that I want to show you is this plan, which is a real catastrophe. Right? We are going to, what I want to show you is what SQL Server is kind of doing when you mismatch data types badly, especially dates.

Right? So this is sort of the plan shape that I warned you about before, where you’ve got constant scan, compute scaleR, merge interval, and then a nested loops join to go find stuff. Right?

And this is because down in here, we created our table with a date time data type for the column. Right? We converted that column to a date. And then we asked where it was between a date and a date time 2, 7.

So SQL Server does have all sorts of stuff to do. If you open up the plan XML, this stuff doesn’t show up. This stuff doesn’t show up if you just look at the query plan.

But you’ll see stuff like this in query plans where SQL Server has to do extra work, get range through convert, get range with mismatched types. These are optimizer rules that SQL Server has built in. To try and help you or try to help queries that use mismatched data types do the right thing.

You can see where SQL Server is converting stuff and all that. So it’s extra effort for the optimizer to have to deal with your queries. This is a very interesting problem that my friend Martin Smith ran into with strings.

If you go to this link, you’ll be able to see the issue that Martin opened up here. Martin Smith, very smart fella. Incredible with SQL Server stuff.

One of my absolute heroes. And what he found was a very interesting problem where we have a VARCAR50 column collated like so. It is nullable.

And then what we would do is insert 20 null values into them. Get a count from the table. And then we would select another count from the table. And we would say where problem child equals this or problem child is null.

Now, this one is actually a little bit perilous because I verified this on SQL 22. But I said, I just started using SQL Server 2025. If it doesn’t repro here, good job, Microsoft.

If it does, you stink. Just kidding. You’re busy. You got a lot of fabric weaving to do. So let’s see if this thing still repros on SQL Server 2025. Let’s see.

It does. So we get so when we do a regular count from the table, we return the 20 rows, right? Because, I mean, just like you can see, I am very much limiting this to 20 rows going in, right?

Top 20. Generate series 1 through 20. When we do a count from the table, SQL Server correctly says there are 20 rows in there. But when we say where problem child equals, we have this Unicode string in there, right?

So we have an implicit conversion. Or it’s null. SQL Server counts 40 rows instead of 20 rows. Very interesting stuff.

And, of course, the execution plan looks just like some of the other execution. Well, I guess there’s an extra operator in there where it looks a lot like a lot of the other query plans I’ve shown you with this sort of weird constant scan concatenation top end merge interval situation over here. And then we have…

I should have highlighted the select so it stayed where it was supposed to be. And then over here we have our dynamic seek where SQL Server is doing an implicit conversion on our VARCHAR column. And it’s saying, is it this or is it null, right?

And, of course, we get back twice as many rows as actually exist in the table. So thank you, Martin Smith, for that wonderful demo. High five from wherever you are in the world.

I believe, according to his Stack Exchange profile, he lives in Rugby, England. Hopefully that’s not Dachshund. I never want to give away too much information. But thank you, Martin.

You are a wonderful, smart, brilliant human being. And I don’t know. I wish we got to spend more time together. You may probably don’t feel the same way. I understand. But I think you’re great.

Anyway, that’s enough for today. Thank you for watching. I hope you enjoyed yourselves. I hope you learned something. And I will see you next week on Tuesday for Office Hours. All right.

Thank you.

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.

The post Learn T-SQL With Erik: Don’t Be Slack With Data Types appeared first on Darling Data.

Building on Microsoft 365 Copilot? Here’s your playbook.

Register: The Microsoft 365 Copilot Agent’s Playbook | Microsoft Reactor

Who Should Join?

• Extend agents with skills and actions
• Ground agent responses with enterprise context using WorkIQ
• Connect MCP apps to create richer interactive experiences
• Evaluate and improve agent quality with Microsoft 365 Copilot Evals

Schedule

What You’ll Learn

• Useful: designed around real user tasks and workflows
• Grounded: informed by relevant enterprise context
• Extensible: connected to actions, skills, and MCP-powered experiences
• Measurable: evaluated and improved with modern developer tools

Get Ready for the Series

• Familiarity with declarative agents, and Microsoft 365 Copilot extensibility concepts covered here https://microsoft.github.io/copilot-camp/pages/extend-m365-copilot/ in Copilot Developer Camp
• Questions for the live Q&A with Microsoft product and engineering teams around these topics.

Don’t Miss the Microsoft 365 Copilot Agent’s Playbook

The post The Microsoft 365 Copilot Agent’s Playbook: A Practical Livestream Series for Building Better Agents appeared first on Microsoft for Developers.

MySQL Enterprise Monitor was a tool many database administrators turned to in times of need – that was, until Oracle Enterprise Manager for MySQL came along and stole the show, leading to its phasing out at the start of 2025. Plenty of DBAs have since made the switch to Enterprise Manager, but have you?

If the answer’s ‘no’, I’ll explain why you should make the upgrade, and how to do it.

But first, let’s take a step back and compare the two tools – looking at what they are, and why they’re useful.

While MySQL Enterprise Monitor is phased out (so is no longer supported by Oracle), it is still usable as of the time of writing in 2026 – hence not using the past tense when describing it.

What is MySQL Enterprise Monitor?

If you know your way round MySQL, you’ve likely heard of MySQL Enterprise Monitor – a tool designed to help database administrators with a variety of tasks. Some of its features include:

Query analyzer

Analyze the performance of SQL queries. Useful for learning which queries run on which database, when they were first seen, their latency, affected rows, and more.

Database I/O status page

MySQL Enterprise Monitor comes with a database file I/O (input/output) page, allowing users to filter I/O by file, wait type, or by thread. It also enables DBAs to see what’s happened inside their database in the last hour, 2 hours, 6 hours, 12 hours, the last day, or the past week.

Replication and cluster status page

By providing an easy-to-observe topology, MySQL Enterprise Monitor allows developers to see what’s happening with their replication setups.

MySQL Enterprise Monitor backup dashboard

MySQL Enterprise Monitor has a backup section where database administrators can invoke full, incremental, or differential backups of their database instances.

…and more

MySQL Enterprise Monitor came with MySQL Enterprise Edition. It’s just one of many advanced monitoring and management tools available for all kinds of DBAs.

Since, during its lifespan, it was included in MySQL’s enterprise suite of tools, it’s safe to say it had an honorable place in that collection. For many, it provided an easy-to-observe interface into server status, its deep knowledge of MySQL internals ensured accurate intelligence from the start and, with the tool only needing a small footprint on the disk, it quickly became a favorite.

However, it wasn’t perfect. As powerful a tool it was, DBAs had a tough time when they needed to monitor more than a handful of database instances at once, it lacked advanced analytics features, and some of its customization capabilities were a hassle as well.

So, when the improved MySQL Enterprise Manager came along, many DBAs made the switch without hesitation. It was further emphasized in Frederic Descamps’ May 2025 blog post declaring that “MEM is dead, long live Oracle Database Management.”

What is Oracle Enterprise Manager for MySQL?

After Enterprise Monitor’s discontinuation, MySQL now offers two options for you to choose from: Oracle Enterprise Manager for MySQL, or Oracle Cloud Infrastructure (OCI) Database Manager.

Oracle Enterprise Manager for MySQL is a tool built for large-scale MySQL deployments. Also referred to as EM4MySQL, it offers advanced analytics (query fingerprinting, customizable dashboards, etc.), automation (auto-tuning, scheduled maintenance, healing), and integrations (connectors for Oracle Enterprise Manager, Prometheus, and Grafana).

Oracle Enterprise Manager for MySQL vs MySQL Enterprise Monitor – which is best?

Let’s now compare the two tools directly:

As you can see, the advantages of MySQL Enterprise Monitor include its query analyzer, I/O status page, replication and clustering status page, and its ability to conveniently take backup copies of your database when necessary. Many DBAs got used to – and enjoyed – these features.

In comparison, Oracle Enterprise Manager for MySQL is more scalable, can be integrated with a variety of tools, comes with a better-looking UX, and has a richer set of features in general.

Oracle Enterprise Manager for MySQL or MySQL Enterprise Monitor – which should you use?

If your environment is growing, or if your team only needs basic monitoring (without, for example, any integration with Prometheus or other tools), there’s no need to switch to Oracle Enterprise Manager for MySQL just yet. The older MySQL Enterprise Monitor will still be fine for you.

However, if your database environment is growing significantly, you’re looking for automated tuning suggestions, self-healing, and high-performance monitoring, it may be wise to switch to Oracle Enterprise Manager for MySQL instead.

While it does require some getting used to, it is extremely scalable and comes with many advanced analytics-related features for queries, indexing, connections, and more. It also integrates seamlessly with modern tools like Prometheus and Grafana, and supports advanced security features not supported in Enterprise Monitor.

One last thing…

If your monitoring needs extend beyond MySQL — let’s say, a mixed estate with SQL Server or PostgreSQL — a cross-platform tool like Redgate Monitor is worth a look, since it covers MySQL alongside other engines from a single pane of glass.

The post Comparing MySQL Enterprise Monitor with Oracle Enterprise Manager for MySQL – which is best? appeared first on Simple Talk.

2026-07-23

• Typing ? while the /search bar is open enters it as text instead of opening quick help
• Add support for Open Plugin Spec v1 plugin manifests and mcp.json configuration
• IDE integration reconnects reliably when the CLI reloads MCP servers or changes directory
• Multi-turn subagent timelines show every prompt and response in the correct order after reopening /tasks
• Subagent timelines identify whether prompts came from the main agent or another subagent
• Show a first-run splash to opt into the default sandbox
• Adding support for gemini-3.6-flash
• The /mcp add and /mcp edit wizard now preserves = characters in environment variable values (such as base64 padding), so secrets and tokens are stored correctly.
• Remote session uploads stop retrying permanent Mission Control 400/404 responses
• Show Tab in /settings footer to switch scope tabs
• Downscale oversized tool-result images so CAPI Responses requests continue
• When multiplexing sessions, a session's open dialog no longer leaks into another session; eligible pickers reopen when you switch back
• The $ interactive shell shortcut now opens a shell even while the agent is working
• Fully honor the skill disable-model-invocation flag
• Warn when a participating language server reports a different symbol than the one requested
• Steering interrupts shell output waits without stopping the running command
• Increase the Responses request size limit
• Plan mode now allows session-folder planning artifacts while still blocking clear file mutations outside the session folder.
• Add /model plan (or /model --plan) to pick a model used while in plan mode; pass a model id, off to clear, or no id to open the picker. Reverts to the session model when you leave plan mode.
• Resume search matches session titles even when whitespace differs