An Azure cloud SQL database is a fully managed relational database service that runs in Microsoft Azure, with Microsoft handling patching, backups, high availability and the underlying servers. You keep control of your data, schema and access. This guide explains how the service works, what it costs to run, how it compares with SQL Server on premises and when a different Azure data service is the better fit.
Table of Contents
What is an Azure cloud SQL database?
An Azure cloud SQL database is a relational database hosted in Microsoft Azure as a managed service. Microsoft’s documentation describes Azure SQL Database as a platform as a service database engine that handles upgrading, patching, backups and monitoring without user involvement. You manage the data and the design, Microsoft manages the platform.
In practice the phrase covers three different ways to run SQL Server technology in Azure. Azure SQL Database is the fully managed option for individual databases. Azure SQL Managed Instance is a managed copy of a full SQL Server instance. SQL Server on an Azure virtual machine gives you the complete product on a server you control. Most people searching for an Azure cloud SQL database mean the first one, and it is where we start with most clients.
A database is rarely a project on its own. It is usually the data layer inside a wider integration picture, where a CRM, a finance system and reporting all need to read and write the same records. If that is the problem you are actually solving, our business systems integration guide covers how the pieces fit together, and this post goes deep on the database layer itself.
What is the difference between Azure SQL Database, SQL Managed Instance and SQL Server on an Azure VM?
Azure SQL Database is a fully managed single database, SQL Managed Instance is a fully managed SQL Server instance and SQL Server on an Azure VM is the full product on a server you patch yourself. The more control you take, the more operational work you inherit. Most new business workloads fit the first option.
The table below compares the three options as Microsoft positions them in the Azure SQL overview.
| Azure SQL Database | SQL Managed Instance | SQL Server on Azure VM | |
|---|---|---|---|
| Management | Fully managed, database scope | Fully managed, instance scope | You manage the OS and SQL Server |
| Compatibility | Most database-level features | Almost all instance-level features | Full parity with on-premises SQL Server |
| Best for | New applications and single workloads | Lift and shift of complex SQL estates | Legacy systems that need full control |
| Network | Public endpoint with firewall and private endpoint options | Sits inside your virtual network by design | Whatever you build |
| Operational load | Lowest | Low | Highest |
Across our own systems and client work we default to Azure SQL Database first and only step up when a workload proves it needs more. The usual trigger for Managed Instance is instance-level features like SQL Agent jobs or cross-database queries baked into an older application. The usual trigger for a VM is a vendor application that certifies only against the boxed product.
How does Azure SQL Database compare with SQL Server on premises?
The core engine is the same, the operating model is not. On premises you own the hardware, the patching, the backup schedule and the disaster recovery plan. In Azure SQL Database, Microsoft runs all of that as part of the service and you pay a monthly operating cost instead of buying servers and licences up front.
Here is how the two models compare on the things that actually generate work.
| Aspect | SQL Server on premises | Azure SQL Database |
|---|---|---|
| Hardware and patching | Your team or your IT provider | Microsoft, automatic |
| Backups | You schedule, store and test them | Automatic, point-in-time restore built in |
| High availability | You design and pay for it | Built into the service, zone redundancy optional |
| Scaling | Buy and install bigger hardware | Scale up, down or serverless without downtime |
| Cost shape | Capital spend plus licences | Monthly operating cost per resources used |
The pattern we see in Australian small and mid-sized businesses is not a considered choice to stay on premises. It is an ageing SQL Server that came with a line-of-business application years ago, still running on a server nobody wants to touch. When that application comes up for replacement or modernisation, the database conversation is really a hosting conversation, and the comparison above is the honest starting point. Our legacy modernisation service exists almost entirely because of those servers.
How does Azure SQL Database pricing work?
Azure SQL Database has no single price. You choose a purchasing model, vCore or DTU, and within vCore you choose provisioned or serverless compute. The bill reflects the compute, memory and storage you allocate or consume. We deliberately quote the models and not dollar figures here, because the rates change and the model choice matters more.
The three models work like this:
- vCore provisioned. You pick a number of virtual cores, memory and storage, and pay a fixed rate per hour whether the database is busy or idle. Predictable and the right shape for steady production workloads. The vCore model also supports Azure Hybrid Benefit, which discounts the SQL licence component if you already own licences with Software Assurance.
- DTU. An older blended unit of compute, memory and IO in preset tiers. Simple, but harder to reason about when performance problems appear, and it has no serverless option.
- Serverless. Compute scales automatically with load and is billed per second of use. When the database sits idle past its delay period it pauses automatically and you pay for storage only until activity returns.
The cost traps we see are behavioural, not technical. Development and test databases get provisioned like production and left running around the clock. Serverless databases never pause because one management tool or application connection pool stays open, which keeps compute billing while everyone assumes the database is asleep. The fix in both cases is a sizing review, which takes an hour and routinely halves a monthly bill. That is the review we run at the start of most Azure engagements.
How do backups and high availability work in Azure SQL Database?
Backups are automatic and continuous. Azure SQL Database takes regular full, differential and log backups and by default retains enough to restore to any point in the last 7 days, configurable from 1 to 35 days, per Microsoft’s automated backups documentation. Long-term retention can keep full backups for up to 10 years for compliance.
High availability is built into the service rather than bolted on. Every database carries an enterprise-class availability SLA, which increases when you enable zone redundancy so the database survives the loss of an entire data centre within the region. On premises, matching that would mean a second server, a clustering technology and someone to maintain both.
Two practical notes from running this in production. First, a restore creates a new database beside the original rather than overwriting it, which is safer than it sounds once you are used to it. Second, retention settings are a decision, not a default. A 7 day window is fine until someone discovers a data problem three weeks after it happened. For anything a business depends on we set retention deliberately and test a real restore, because a backup you have never restored is a hope, not a plan.
Can an Azure cloud SQL database keep data in Australia?
Yes. Azure operates four Australian regions, listed on Microsoft’s geographies page as Australia East, Australia Southeast, Australia Central and Australia Central 2, and you choose the region when the database is created. Microsoft’s data residency commitment states that customer data will not be stored or processed outside the customer-specified geography without your authorisation.
For most of our clients we deploy to Australia East in New South Wales, with Australia Southeast in Victoria as the pair for geo-redundant backups. That keeps both the live database and its backup copies onshore.
One distinction worth being direct about: data residency is not the same as data sovereignty. Residency controls where the data physically sits. Sovereignty questions, such as which legal jurisdictions can compel access, are a legal and compliance matter beyond a region setting. If you operate under specific regulatory obligations, map those obligations properly rather than treating an Australian region as the whole answer. That mapping is our view of the right process, not legal advice.
How do you migrate an existing database to Azure SQL?
A migration to Azure SQL is a sizing exercise, a compatibility check and a rehearsed cutover, in that order. Most small and mid-sized business databases move cleanly because Microsoft’s assessment tooling flags blockers before anything is committed. The work is in the testing, not the copying.
The process we run looks like this:
- Assess compatibility. Run Microsoft’s assessment tooling against the current database to flag anything Azure SQL Database does not support, and decide up front whether the target is a single database or Managed Instance.
- Size the target smaller than you think. On-premises servers are usually overprovisioned. Start modest, measure, then scale, because scaling up later is an online operation.
- Run a trial migration. Move a copy into a non-production database and point a test instance of the application at it. This is where the surprises surface.
- Plan and execute the cutover. Agree the window, migrate the final data, repoint connection strings and verify the application against a checklist you wrote before the day.
- Decommission deliberately. Set backup retention, alerting and access on the new database, then retire the old server. The migrations that go wrong are usually the ones where the old server quietly stays on.
If the system you are moving off is Microsoft Access rather than SQL Server, the path is different enough that we wrote it up separately in our Access to SQL Server migration guide. And if the migration is part of a broader data movement problem, our Azure Data Factory training guide covers the tooling that moves data between systems on a schedule.
How does an Azure cloud SQL database fit into a modern architecture?
In a modern Azure architecture the SQL database is the transactional core. Applications on Azure App Service read and write to it, automation tools act on its records, APIs expose it to other systems and Power BI reports over it. The database holds the truth, everything else connects to it.
That is not theoretical for us. Jacky, the AI agent on our own website, runs on exactly this pattern: an Azure App Service front end with Azure SQL as the data layer. It answers visitors 24/7 with an average first reply under 2 seconds, and every qualified enquiry is written into our CRM with zero manual data entry. The database is unglamorous in that story, which is the point. It has to be reliable enough to be boring while the visible parts do the work.
The connective tissue around the database matters as much as the database itself. Wiring an Azure SQL database into a CRM, a finance system or a customer portal is API work, and it is where projects succeed or stall. That layer is covered by our API and integration services.
When is an Azure cloud SQL database the wrong choice?
Azure SQL Database is the wrong choice for large-scale analytics, for document and file storage, for small structured lists that already have a home in Microsoft 365 and for legacy applications that need a full SQL Server instance. It is a transactional database, and it is best when used as one.
The most common mistake we see is not choosing Azure SQL, it is defaulting to it. Reporting workloads that aggregate millions of rows from multiple systems belong in an analytics platform such as Microsoft Fabric or a data lake, not in the same database that runs your application. That boundary, transactional data in SQL, analytical data in a purpose-built pipeline and analytics layer, saves both money and performance pain.
At the other end of the scale, a 200-row list of assets or approvals does not need a database at all. A SharePoint list or Dataverse table does that job inside the licences you already pay for. And an old vendor application that demands SQL Agent jobs, cross-database queries or a specific SQL Server version belongs on Managed Instance or a VM rather than being forced into the single database service.
Frequently asked questions
Is Azure SQL Database the same as SQL Server?
They share the same database engine but they are not the same product. SQL Server is software you install and maintain on your own servers. Azure SQL Database is a managed service where Microsoft runs the engine, applies patches and takes backups. Most database-level features carry across, while instance-level features such as SQL Agent belong to SQL Server and Azure SQL Managed Instance instead.
When should you use serverless instead of provisioned compute?
Use serverless for databases with genuinely intermittent use, such as development, test and internal tools that sit idle overnight, because compute is billed per second and pauses when the database is inactive. Use provisioned compute for production workloads with steady traffic, where a fixed hourly rate is cheaper than paying per second all day and the database should never pause.
How much does an Azure cloud SQL database cost for a small business?
It depends on the purchasing model and the resources you allocate, so treat it as a monthly operating cost you control rather than a fixed price. A lightly used serverless database costs very little because you pay for storage plus seconds of compute. A provisioned production database costs a predictable monthly amount based on its size. The biggest savings come from right-sizing, not from the model itself.
Do you need a database administrator to run Azure SQL Database?
Not a full-time one for most small and mid-sized businesses. Microsoft handles patching, backups and availability, which is most of what a traditional DBA spent time on. You still need someone accountable for schema changes, access control, performance tuning and cost review, which is typically a fractional or on-call arrangement rather than a hire.
Does Azure SQL Database work with Power BI?
Yes, it is one of the most common Power BI sources. Power BI connects directly using import or DirectQuery modes, and for heavier reporting we usually stage data out of the transactional database first so reports never slow down the application. That staging pattern matters more as data volumes grow.
What happens to an Azure SQL database when nobody is using it?
On the serverless tier, the database pauses automatically after its configured idle period and you pay only for storage until the next connection resumes it, which takes a few seconds. On provisioned compute, the database stays online and bills at its fixed rate whether or not anyone is connected, which is why idle provisioned databases are the first thing we look for in a cost review.
Where to start with an Azure cloud SQL database
Start with the workload, not the platform. If you are replacing an ageing server, modernising a legacy application or building something new, the right database option falls out of a short sizing and architecture conversation, and the wrong one falls out of defaults. We design, migrate and run Azure SQL databases for Australian businesses, and we run the same platform ourselves. If you would like a second opinion on a design, a migration plan or a bill that looks too high, get in touch and we will talk it through.
