Azure SQL Database is a managed relational database service that runs in the Microsoft cloud.

Let us break the name into pieces. Azure is Microsoft’s cloud platform, a huge collection of computers in data centers around the world that you can rent as you need them. A database is an organized collection of information stored so that programs can add, find, change and remove it quickly. SQL stands for Structured Query Language, the standard language programs use to talk to relational databases. Put together, Azure SQL Database is a relational database, built on the Microsoft SQL Server engine, that lives in Azure.

The most important word in its description is managed. When you install a database yourself, you must buy or rent a computer, install the software, apply security updates, set up backups, arrange for a spare server in case of failure, and watch it day and night. With Azure SQL Database, Microsoft does all of that. This kind of service is called Platform as a Service, or PaaS: you receive a ready-to-use platform and you only look after your own data and the way your application uses it.

Before using the service, you need a picture of what a relational database actually stores.

A relational database keeps information in tables. A table looks like a spreadsheet page. Each column describes one kind of fact, such as customer name or order date, and each row holds one complete record, such as one particular customer. A shop might have a Customers table, a Products table and an Orders table.

The word relational comes from the fact that tables can be linked to each other. An order row does not repeat the customer’s whole address; it just points to the matching customer row using an identifier called a key. This saves space, avoids mistakes, and means that if a customer moves house you change the address in only one place.

Azure SQL is a family of three offerings, and Azure SQL Database is the most hands-off of them.

Many beginners are surprised to learn that “Azure SQL” is not a single product. Microsoft offers three ways to run SQL Server technology in Azure, each giving a different balance between control and convenience.

flowchart TD
    S["Need a SQL database in Azure"] --> Q1{"Building a new cloud app?"}
    Q1 -- Yes --> A["Azure SQL Database"]
    Q1 -- No --> Q2{"Moving an existing app with few changes?"}
    Q2 -- Yes --> Q3{"Needs instance-level features?"}
    Q3 -- Yes --> B["Managed Instance"]
    Q3 -- No --> A
    Q2 -- No --> Q4{"Needs full OS or engine control?"}
    Q4 -- Yes --> C["SQL Server on a VM"]
    Q4 -- No --> B
        

If you are starting a brand-new project, Azure SQL Database is usually the best place to begin. Choose the others only when you have a clear reason, such as a feature that the Database service does not offer.

A database in Azure lives inside a logical server, which acts as its administrative home.

When you create an Azure SQL Database, you are asked to pick or create a logical server. This word confuses many beginners, because it is not a computer you can log into. It is a management container that holds settings shared by a group of databases: the login names, the firewall rules that decide who may connect, the security policies, and the address that applications use to reach the databases.

The databases themselves run on Microsoft’s hardware, and Azure decides where. The logical server simply gives you one place to manage access and rules. Deleting the logical server deletes every database inside it, so treat it with care.

What lives at the server level

You can give each database its own resources, or let several databases share a pool.

Single database

A single database is the simplest choice. It has its own dedicated amount of compute power and storage, and you pay for exactly what you set. It is isolated from other databases, so a busy neighbor cannot slow it down. This suits an application with a steady, predictable load.

Elastic pool

An elastic pool is a shared bucket of resources for several databases on the same server. Each database can use as much as it needs from the bucket, within limits you set. This works wonderfully when you have many databases whose busy moments happen at different times, because the quiet ones leave room for the busy ones.

Azure offers two ways to describe and pay for the power of your database.

The DTU model

DTU stands for Database Transaction Unit. It is a single blended number that combines processing power, memory and input and output speed into one simple unit. You pick a tier named Basic, Standard or Premium, and then a size within it. The advantage is simplicity: you do not need to understand the hardware. The drawback is that you cannot tune each ingredient separately, so it is harder to know exactly what you are paying for.

The vCore model

A vCore is a virtual core, a slice of a real processor. In this model, you choose the number of virtual cores, and memory and speed scale with them. You also choose the service tier and the hardware generation. Because the pieces are clear, this model gives you more control, makes it easier to compare with your on-premises servers, and offers extra savings options such as reserved capacity and the Azure Hybrid Benefit, which lets you reuse existing SQL Server licenses. The vCore model is generally recommended for new projects.

In the vCore model, the tier decides how the database is built underneath and how it behaves.

General Purpose

In General Purpose, the part that runs your queries is separated from the part that stores data files. If the compute side fails, Azure starts a replacement and connects it to the same storage. This is dependable and cost-effective, with a short pause during the switch. It supports databases up to a few terabytes and suits websites, internal business tools and many everyday applications.

Business Critical

Business Critical keeps data on fast local solid-state drives attached to the compute machine, and runs several copies of the database at once on separate machines. One is the primary, and the others are secondaries that receive every change. If the primary fails, a secondary takes over almost immediately. One secondary is also readable, so you can send reports to it and keep the primary free for transactions. This tier suits systems where every second of downtime and every millisecond of delay costs real money.

Hyperscale

Hyperscale splits the database into layers: compute nodes, a log service that records changes, and page servers that hold the data in pieces. Because the data is spread across many page servers, the database can grow very large, backups are taken quickly using storage snapshots, and restores finish in a short time even for huge databases. You can add read-only replicas to spread the reading load. It is a strong choice for large or fast-growing databases.

Serverless lets a database scale automatically and even pause when nobody is using it.

With provisioned compute, you reserve a fixed number of vCores and pay for them every hour, whether or not the database is busy. This gives steady performance and is ideal for databases that are used all day.

With serverless compute, you set a minimum and maximum number of vCores. The database automatically moves between them depending on demand, and you are billed for the compute actually used, measured by the second. You can also set an auto-pause delay: after a period with no activity, the database pauses, and you then pay only for storage. When a new connection arrives, the database resumes, which takes a short time.

Every connection passes through several checks before a single row is returned.

It helps to follow the journey of one request. Suppose a shopping app wants to show a customer’s last five orders. The application opens a connection to the logical server’s name. The request first reaches a gateway, a front door service that checks the firewall rules and finds where the target database is running. Depending on the connection policy, the gateway either keeps passing traffic along or hands the application a direct address to the database’s own node. The database then checks the login, runs the query, and returns the rows.

sequenceDiagram
    participant App as Application
    participant GW as Gateway
    participant FW as Firewall Rules
    participant DB as Database Node
    App->>GW: Open connection to server name
    GW->>FW: Is this address allowed?
    FW-->>GW: Allowed
    GW->>DB: Route to the right database
    App->>DB: Sign in and send query
    DB-->>App: Return rows
        

Why this matters to you

Because the database can move between machines during maintenance or failover, your application should never depend on a fixed machine address. Always use the server name, and let your application retry briefly if a connection drops. Short interruptions of this kind are called transient faults, and well-written applications are designed to handle them gracefully.

You decide exactly who and what can even reach your database.

By default, a new Azure SQL Database is closed to outsiders. You open doors deliberately, using one or more of the following controls.

Authentication proves who someone is, and authorization decides what they may do.

These two words are often mixed up. Authentication asks, “Are you really who you claim to be?” Authorization asks, “Now that I know who you are, what are you allowed to do?” Azure SQL Database supports two main sign-in methods.

Managed identities for applications

Applications also need to sign in, and storing a password inside an application is risky. A managed identity is an identity that Azure creates for an application and manages automatically. The application proves itself to the database without any password in its settings. This removes a very common source of leaks.

Least privilege

Inside the database, you give each person or application only the permissions they need and nothing more. A reporting tool that only reads data should never have the right to delete tables. This principle is called least privilege, and it limits the damage if an account is ever misused.

Even if someone gets past the gate, several layers protect the information inside.

Together, these features give you defense in depth, the idea that no single protection should be the only barrier. If one layer fails, another still stands in the way.

Azure takes backups for you automatically, so you can travel back to an earlier moment.

You never need to schedule backups for Azure SQL Database. The service takes them automatically: a full backup about once a week, differential backups that capture changes since the last full one every few hours, and transaction log backups roughly every ten minutes. Together, these let Azure rebuild the database as it was at almost any moment inside your retention window. This ability is called point-in-time restore.

The service is built so that the failure of one machine does not take your database offline.

High availability means a system keeps working even when parts of it break. Azure SQL Database includes this without extra setup, and the method depends on your tier. In General Purpose, a failed compute machine is replaced by a new one that reattaches to the same durable storage. In Business Critical, several live copies run on separate machines, so another takes over almost at once. In Hyperscale, the layered design and optional replicas provide fast recovery.

Zone redundancy

An availability zone is a separate data center building within a region, with its own power, cooling and network. If you turn on zone redundancy, the copies of your database are placed across different zones, so the loss of an entire building does not stop your database. This raises the availability target and is recommended for important production systems, though it can add cost.

Geo-replication and failover groups keep a live copy in a faraway region.

A region is a geographic area containing Azure data centers. Rare events such as large power failures or natural disasters can affect an entire region. For systems that cannot wait for a long restore, Azure SQL Database offers two tools that keep a continuously updated copy in another region.

flowchart LR
    APP["Application"] --> RW["Read-write listener name"]
    APP --> RO["Read-only listener name"]
    RW --> P["Primary database: Region A"]
    RO --> S["Secondary database: Region B"]
    P -- "Continuous replication" --> S
    P -. "If Region A fails" .-> F["Failover: Region B becomes primary"]
        

Two numbers to know

Disaster planning uses two terms. Recovery Point Objective, or RPO, is how much recent data you can afford to lose, measured in time. Recovery Time Objective, or RTO, is how long you can afford to be offline. Because replication to another region has a small delay, a forced failover may lose a few seconds of the newest changes. Decide your RPO and RTO with the business before choosing a design.

You can grow your database’s power with a few clicks and let Azure help tune its queries.

Scaling up and down

If your database becomes slow because it needs more power, you can change its size or tier. In many cases the change happens online, with only a very brief connection drop at the end. When demand falls, you can scale back down to save money. This flexibility is a major advantage over buying physical servers that you cannot easily shrink.

Reading without disturbing writing

Reports that scan huge amounts of data can slow down the everyday transactions of an application. With Business Critical and Hyperscale, you can send read-only work to a readable secondary, leaving the primary free for the shop’s real customers.

Automatic tuning

Azure SQL Database includes automatic tuning, which watches how queries behave and offers fixes. It can notice that a new plan for a query is slower than the previous one and switch back to the better plan. It can also suggest or create helpful indexes and remove ones that are never used. You can let it apply changes by itself or only recommend them for your review.

A few key measurements tell you whether your database is healthy or struggling.

Azure Monitor collects metrics from your database. A metric is simply a number measured over time. You can display them on charts and set alerts that send a message when a value crosses a limit.

Tools that explain the why

Numbers tell you something is wrong, but not why. Query Store is a built-in feature that records the history of your queries and their plans, so you can find which ones became slower and when. Query Performance Insight presents this in a friendly view in the Azure portal, showing the top resource-hungry queries. Intelligent Insights goes further and tries to describe the cause of a slowdown in words.

Migration is a planned journey with assessment, transfer, testing and switch-over.

Many teams already have a SQL Server database running in their own office or data center. Moving it to Azure SQL Database is a common project, and Microsoft provides tools that make it safer.

Your bill comes from compute, storage, backups and extras, and each can be tuned.

The cost of Azure SQL Database has a few main parts. In the vCore model, you pay for compute, either a fixed hourly amount for provisioned databases or per-second usage for serverless ones, and you pay separately for the storage you reserve. Backup storage beyond a free allowance, long-term retention, extra replicas, and zone redundancy can add further charges. In the DTU model, compute and a set amount of storage are bundled into one price.

Habits that experienced teams follow, and traps that beginners often fall into.

Seeing how the options combine in real projects makes the choices easier to remember.

They share the same core engine and the same SQL language, so most skills and tools carry over. However, SQL Server is software you install and manage yourself, while Azure SQL Database is a managed cloud service where Microsoft handles the servers and updates. Some instance-level features of SQL Server are not available in the Database service.

No. Microsoft applies updates and security fixes automatically, and the engine stays current. You may notice very brief connection interruptions during maintenance, which is why retry logic in your application is important.

Yes. You can scale compute and often change between tiers when your needs change. The change usually happens online with a very short interruption at the end. Some switches have special conditions, so check the documentation for your case.

Azure keeps backups for a period after deletion as part of the retention settings, so a deleted database can often be restored within that period. The exact window depends on your configuration, so confirm your retention settings and consider resource locks on important databases.

Yes. Transparent Data Encryption is on by default for new databases, and connections can be required to use encrypted TLS channels. You can add stronger options such as Always Encrypted and customer-managed keys if your rules demand them.

Choose serverless when usage is irregular, with long quiet periods, such as development, testing or small internal tools. Choose provisioned when the database is busy for most of the day or when you cannot accept any delay after idle time.

A backup is a recovery point you restore from, creating a new database. Geo-replication keeps a live, continuously updated copy in another region that you can switch to quickly. Backups protect against mistakes, while geo-replication protects against regional outages. Serious systems usually use both.

You do not need one for server tasks like patching and backups, since those are automated. You still benefit from someone who understands data design, security, indexing and query performance, because those skills decide how well your application runs.

Azure SQL Database gives you a fully managed relational database without the burden of looking after servers. You now understand how tables, rows and keys organize information, where the service fits in the Azure SQL family, and how logical servers, single databases and elastic pools are arranged. You have seen how the DTU and vCore models work, how General Purpose, Business Critical and Hyperscale differ, and when serverless saves money. You have also learned how connections are controlled, how data is protected in layers, how backups, high availability and geo-replication cover different kinds of failure, and how monitoring, tuning and careful cost habits keep the service healthy and affordable.

The best approach is to start simple: choose the vCore model, begin with the smallest suitable tier, keep access private, use identities instead of passwords, and test your recovery plans. Grow the design only when real measurements tell you to.