Azure SQL Database

The unit is a database

Most managed database services give you an instance: a server, operated by the provider, that holds databases.

This service gives you a database.

The distinction sounds subtle and it determines how the service behaves.

There is no instance to size, no server level configuration and no host. You ask for a database, state how much capacity it should have, and use it.

For applications this is usually what was wanted. An application needs a database. The server was always an implementation detail that came with obligations attached.

The consequence is that features depending on instance level or host access are not available. Operations spanning databases, certain administrative commands and anything requiring the underlying machine work differently or not at all. The official documentation maintains this list, and consulting it is the necessary first step before a migration rather than a formality.

Buying capacity rather than hardware

Because there is no server, capacity is not expressed as a machine specification.

It is purchased in defined units combining compute, memory and storage. More units means more capacity.

There is also a model that scales with demand and can pause when the database is idle.

That option suits a specific and common shape of workload. A database used heavily during business hours and not at all overnight. A system used for a few days each month. An internal application with a handful of users. Under a model where capacity is provisioned constantly, all of these pay continuously for capacity used intermittently.

Scaling with demand fits those better, with the trade being that a paused database takes time to become available again when a request arrives. Whether that matters depends entirely on the application.

What the service takes on

Patching happens without anyone applying it. Backups are taken and retained, supporting restoration to a point within the retention period. Replicas are maintained for availability by the service rather than configured separately.

The pattern is the same as other managed services and the removal is more complete here, because there is no server left to administer even partially.

Restoring to a point in time deserves particular mention. It covers the most common serious accident with a database, which is not hardware failure but a statement run against the wrong database or without the intended condition. Recovering to just before that happened is what makes such an event survivable.

What remains yours

Managed operation does not extend to how the database is used.

Query performance is still determined by queries and indexes. Schema design is still a decision with consequences. Capacity still has to be appropriate to the workload, and choosing too little produces throttling while choosing too much produces cost.

The service removes the work of operating a database. It does not remove the work of using one well, and expecting otherwise is the most common disappointment with managed services generally.

The parts that do not come with it

SQL Server as a product includes integration, reporting and analysis services. This service is the database engine.

For organisations migrating from a SQL Server installation, this is frequently the complication. The database moves readily; the packages that load it, the reports built on it and the models over it are separate components requiring separate decisions.

Azure provides services covering those functions, and they are separate services with their own migration paths. Planning a move on the assumption that the whole estate transfers as one is where such projects tend to lose their estimates.

Who uses it

Azure SQL Database is used by application teams and platform teams working on Azure, particularly organisations already using Microsoft software where the surrounding tooling and identity arrangements align. It is also common for software providers giving each customer a separate database.

Points to consider

This is a Microsoft Azure service. The official documentation is the reference for purchasing models, capabilities and current limits, all of which change.

Compatibility with an existing SQL Server database should be assessed rather than assumed. Microsoft provides tooling for this assessment, and the differences that matter are specific to what a given database uses.

Cost depends on the model chosen and on the capacity provisioned. The models are not directly comparable to one another, so estimating requires understanding how each is measured rather than comparing headline figures.

Very large or unusually demanding databases may fit other options in the Azure SQL family better. The documentation describes the alternatives and what distinguishes them.

Getting started

The official documentation covers purchasing models, migration assessment, backups and availability. Creating a small database and pointing an existing application at it establishes quickly how much, if anything, has to change, which is the question that determines whether a migration is straightforward.