I remember when the first SQL databases were available on Azure. The size limits and missing features made them impractical for most uses at the time. Fast forward 10 years and you can you create a terabyte database and take advantage of configurations like Hyperscale, Elastic Pool, and Managed Instances. You get automatic high-availability and backups, and many features show up in Azure SQL Database before they do in on-premises versions.

The latest option is called Azure SQL Database Serverless, generally available since last November. I have been hearing this term for months, but I hadn’t looked into what it actually means until recently. Even though you do not need to manage a server for Azure databases unless you choose to host your instance in a virtual machine, I found that the Serverless configuration has an interesting advantage depending on your use case.

Serverless is meant for workloads that are intermittent and unpredictable. That means that you can pause the database when it’s not in use and scale up resources as the workload increases. The pausing and resource scaling can all be automatic. If the database is paused, it will “wake up” and begin working again when a connection is made. The advantage of pausing the database and adjusting the resources is that you only are charged for what you use. The disadvantages are that you must be willing to tolerate reconnecting after an initial error and some latency as the database first goes back online.

The billing for the compute is based on how many cores are used per second. You can configure the database for a maximum of up to 40 vCores. You can also configure the minimum vCores setting, but the options change based on the max setting you choose. The memory range is automatically sized based on the vCores settings. While the billing for compute pauses along with the database, you are still charged for storage.

Another thing I appreciate is that you can switch an existing database to this model. When you do, you can see the cost summary for all the options. The configuration and cost information is helpful for coming up with just the right configuration for your situation. If you need a database that is accessed during certain hours or if the usage requirements fluctuate dramatically, this could be the right option for you. Over time, you may decide that another service tier would be better, and it’s easy to make the change. It doesn’t matter whether you are creating a new database or moving an existing database, you have the options of using the Azure Portal, PowerShell or the Azure CLI to do the work. Published tutorials and quickstart articles make this easy.

Microsoft first offered a Database-as-a-Service ten years ago. In those years, Azure SQL Database has matured from a small database that was missing many features to a fantastic array of options to fit the needs of just about any enterprise.