Azure
Azure SQL Database or SQL Server on a VM? What I Learned
Both run SQL Server. The difference is who patches it, who backs it up, and how much control you actually need. For my API, handing all of that to Azure was the obvious call.
When I deployed the Sports Betting API to Azure, I needed a database behind it, and there were two obvious options: Azure SQL Database, the managed service, or a virtual machine with SQL Server installed on it. Both run SQL Server. The difference is everything around the database, not the database itself.
What the VM option actually means
A VM with SQL Server on it is a machine I own. I pick the size, install SQL Server, configure it, and it behaves exactly like a SQL Server on any other machine, because that's what it is.
That also means everything about that machine is mine to look after. Operating system updates, SQL Server patches, backups, configuring high availability, making sure the disk doesn't fill up. If a security patch comes out, applying it is my job and my downtime.
The upside is total control. Full access to the instance, any SQL Server feature, any configuration setting, SQL Server Agent jobs, the file system, cross-database queries. If I need something specific at the instance level, it's there.
What Azure SQL Database gives up and gets back
Azure SQL Database is the database as a service. I don't get a machine, I get a database, and Azure handles the operating system, the patching, and the automated backups.
The tradeoff is that some things aren't mine anymore. There's no SQL Server Agent in the same form, no file system access, no instance-level configuration, and things like cross-database queries work differently or not at all. It's SQL Server, but a scoped version of it.
Why I chose the managed one
For my API the decision was straightforward, and it wasn't really about features. It was about what I actually wanted to spend time on.
I'm building an API. I'm not a DBA, and I don't want to become the person responsible for patching a database server on a study project. Every hour spent maintaining a VM is an hour not spent on the thing I'm actually trying to learn. Azure SQL Database means the database is a connection string and nothing else.
The backups mattered too. Automated backups I don't have to configure are worth a lot compared to the alternative, which is me setting up a backup schedule and then discovering later whether it actually worked.
Since the whole application runs on Azure Container Apps and is configured entirely through environment variables, the database being a managed endpoint fits that shape exactly. Nothing in the app knows or cares what's on the other end of the connection string.
When I'd pick the VM instead
There are real reasons, they just didn't apply to me.
If an application needs a SQL Server feature the managed service doesn't support, that settles it. Legacy applications sometimes depend on instance-level behaviour, linked servers, specific agent jobs, or cross-database queries that assume everything lives in one instance.
Migrating an existing on-premises database can also be simpler onto a VM, because it's the same environment it already ran in. Lifting it as-is and changing nothing is less risky than adapting it to a managed service's constraints.
And if a team already has DBAs who know how they want SQL Server configured, giving that control up isn't a saving, it's a loss.
The general rule I took from this
Managed is the default unless there's a specific reason it can't work. The question isn't which one is more capable, because the VM is obviously more capable. It's whether I need that extra capability enough to take on operating a server for it.
For most new applications, and definitely for anything I'm building right now, the answer is no. I'd rather have fewer things that are mine to keep running.