Azure SQL Database is the option people mean when they say they want to get out of the database business, and it delivers that almost completely: no patching, no backups to arrange, no version to plan an upgrade for, and a service level agreement on the database itself rather than on the machine underneath it. What you give up in exchange is the instance. Not some of the instance, the whole idea of it, and that single architectural fact decides which of your databases can move here and which cannot, long before anyone opens a pricing calculator.
A database is the whole unit
Every habit a SQL Server administrator has is built around the instance. The instance is where logins live, where the Agent runs the jobs, where linked servers point outward, where one database queries another by three-part name, where Database Mail sends the alert, and where a backup can be taken and restored on demand. Azure SQL Database keeps the database and discards the container. What you deploy is a logical server, which sounds like an instance and is not one: it is a connection endpoint and an administrative boundary, with no shared instance-scoped surface behind it and no shared engine the way a real instance has one.
This is why so many migration conversations about this service go badly. The team evaluates it on manageability and cost, both of which are genuinely excellent, and only discovers the missing surface when someone asks where the nightly job went. The honest framing is that Azure SQL Database is not a place you move SQL Server to. It is a place you build applications for, and a place you move applications that were written as though the instance was never theirs to use.
Delegating the operation of a database is easy to agree to. Delegating the instance means the application has to have been written not to need one, and that decision was made years ago by someone who is no longer on the project.
The seven things that are simply not there
I check the same list on every assessment, and I check it before anything else, because a single hit on it can end the discussion. There is no SQL Server Agent. There are no cross-database queries by three-part name, with the narrow exception of the current database and tempdb. There is no common language runtime, no Service Broker, no linked servers, and no Database Mail. There are no Windows logins, which means authentication has to be re-founded on Entra identities rather than translated. And there is no native backup or restore at all, in either direction, which is worth pausing on because it surprises even experienced people: you cannot take a backup file off this service, and you cannot restore one into it. Backups exist, they are automatic and continuous and better than most estates manage for themselves, but they are the platform’s, not yours.
Two of those have official answers and both answers carry conditions. Scheduled work moves to elastic jobs, which have been generally available since April 2024 and are a real replacement rather than a gesture, but they are a different product with their own job database, their own authentication model, and their own learning curve, so rebuilding a mature Agent estate on them is a project rather than a migration step. Cross-database querying has a documented workaround in elastic query, and here I would be careful about what you promise: it remains labelled preview, years after it appeared, and the horizontal partitioning pattern built on shard map manager has a published end of support in March 2027. Building a production dependency on a long-running preview whose main pattern already has an end date is a decision to take deliberately, in writing, not one to slide into because it made a diagram work.
Hyperscale is the default now, and the docs argue with themselves about it
The tier advice most people are carrying is a few years out of date. Microsoft’s current service tier comparison describes Hyperscale, in as many words, as the recommended and default service tier for all new and modernizing OLTP and HTAP workloads. That is a significant reversal from the era when Hyperscale was the specialist choice for enormous databases and General Purpose was where everything ordinary went. It is worth knowing, though, that the same rendered page still describes General Purpose as the default service tier a little further down. Microsoft contradicts itself here, and if a client’s procurement team reads one sentence and you have quoted the other, you want to have seen both first.
What makes Hyperscale the sensible default is architectural rather than promotional. It separates compute from a log service and a fleet of page servers, which is why it scales to 128 terabytes, why compute resizes in roughly constant time regardless of database size, and why its backups are snapshot-based and effectively size-independent. You add up to four high-availability replicas and up to thirty named replicas for read workloads. Elastic pools are generally available for it, capped at 100 terabytes per pool rather than the single-database figure, which is a distinction that has caught people out. A serverless variant exists and is generally available, with the significant caveat that it does not auto-pause. The largest compute sizes, at 160 and 192 vCores, are still preview, so do not design a capacity plan that lands on them.
General Purpose has not become wrong, and Business Critical still exists for what it has always been good at: local solid-state storage, an Always On style replica set, and a free read scale-out replica for workloads that genuinely need low latency and high transaction throughput. But the burden of proof has moved. Choosing General Purpose for a new database is now a decision to explain rather than a default to fall into.
Serverless, and the free tier that is genuinely free
Serverless is the shape of this service that has no equivalent anywhere else in the family, and it is underused. Compute scales automatically inside a range and bills by the second, and on General Purpose it will pause the database entirely after an idle period, defaulting to an hour and configurable from fifteen minutes out to a week, or disabled if you would rather it stayed warm. For development environments, for the internal application that three people use on Tuesdays, and for anything with a genuinely intermittent load, this is the tier that makes the economics work. Auto-pause is also a set of constraints in disguise: it is incompatible with geo-replication and failover groups, with long-term retention, and with hosting the elastic jobs job database, so the pattern does not survive being made highly available.
The free offer deserves a mention because it is unusually honest. Every subscription can run up to ten General Purpose serverless databases at no cost, each with a monthly allowance of compute seconds and a fixed data and backup allowance, and when the allowance is exhausted the default behaviour is to pause rather than to bill. That is a genuine sandbox, and it is the fastest way to let a sceptical development team find out for themselves whether their application survives the missing instance.
Versionless, and what that costs you
There is no version number here. The engine is continuously updated and always runs the latest stable build, which is the single largest operational benefit on offer: no upgrade projects, no end-of-support cliff, no cumulative update maintenance window, ever again. It is also a genuine surrender of authority, and the place that surrender becomes visible is the compatibility level.
The supported range runs from 100 to 170, and new databases default to 170. That is worth checking against whatever documentation you have open, because Microsoft’s own feature comparison page still prints the old range of 100 to 160 and has done for some time, while the definitive statement in the language reference has been updated. When two Microsoft pages disagree, the more recently revised one wins, and in this case that is the language reference. The practical point behind the pedantry is that the compatibility level remains yours to set even though the engine version does not, and it is the lever that lets you move a database here without inheriting a new optimiser on the same day. Use it exactly as you would during any upgrade: arrive at the old level, take a baseline, raise it deliberately afterwards.
Evergreen means you will never plan an upgrade again, and never decline one either. That is a good trade for most estates and an unacceptable one for a few, and knowing which you are is the point of the exercise.
What you actually get for availability
Because this is a database service rather than a virtual machine, the service level agreement covers the database, and that is the substantive difference from anything you can build yourself on infrastructure. The numbers live in Microsoft’s consolidated online services agreement rather than on a Learn page, which is a small piece of friction worth absorbing once: the product documentation no longer prints percentages, and the older per-service agreement pages have been retired to the point of returning errors. Read the current document, not a cached figure, and read it again before you print one in a design.
The shape of it is that a zone-redundant deployment carries a higher commitment than a single-zone one, and that this applies across the tiers rather than being reserved for the expensive ones. If you have been carrying the rule of thumb that zone redundancy only improves the commitment on Business Critical, check it against the current document, because that is not what it says today. Zone redundancy is available for General Purpose in both its provisioned and serverless forms, for Business Critical, for Premium, and for Hyperscale, where it has to be chosen at creation time. Basic and Standard on the older purchasing model cannot be zone-redundant at all, which is one more quiet argument for leaving that model behind.
Beyond the zone, geo-replication and failover groups give you a declarative cross-region story with read-write and read-only listeners, so the application does not have to know which region is live. That machinery is genuinely good and it is the part of this service I most often find switched off because nobody made the decision. It is a decision. Make it explicitly.
Where it belongs
Azure SQL Database is the right answer for new development, for applications being genuinely modernised rather than relocated, for software-as-a-service estates that want many small databases under one operational model, and for the long tail of small internal applications where serverless and the free allowance make the running cost close to nothing. It is the wrong answer for a lifted estate with instance dependencies, and the wrongness will not show up in a proof of concept, because a proof of concept restores one database and runs one query. It shows up in month three, when someone goes looking for the job that reconciles two databases overnight and finds that neither the job nor the ability to query across them exists.
The build sheet that follows this article takes a small line-of-business database off an ageing on-premises box and lands it here properly: provisioned with the current defaults, reachable only over a private endpoint, with the logins re-founded on Entra and the scheduled work rebuilt as elastic jobs. It is deliberately the least glamorous migration in this series, because it is the one where the work is all in the things that are not the database.
Azure SQL
‹ Previous: [SQL 1] SQL Server in Azure: Four Options and One Decision
Next: [SQL 2.1] Build Sheet: A First Azure SQL Database, Migrated ›
