Azure SQL Database vs SQL Server: What Changes for a DBA?

A DBA moving from on-premises SQL Server to Azure SQL Database does not stop being a DBA. The work changes because Azure SQL Database is a managed platform service. Microsoft takes responsibility for more of the underlying operating system and database platform maintenance, while the customer still owns important decisions around data, access, performance, resilience, configuration and cost.

The biggest change is the responsibility boundary

With self-managed SQL Server, the organisation owns the server or virtual machine, operating system, SQL Server installation, patching strategy, service configuration and much of the availability architecture. With Azure SQL Database, those infrastructure layers are managed by the service. The companion article on SQL Server DBA roadmap develops this point.

That means many classic server-level tasks disappear, but operational responsibility does not disappear. It moves upward.

What you no longer manage in the same way

• Installing SQL Server on an operating system.
• Managing Windows services for the Database Engine.
• Patching the database engine yourself.
• Configuring physical disks for MDF/LDF placement.
• Managing a traditional SQL Server Agent instance on the same server.
• Building operating-system failover clustering for the managed database service.

What still matters

• Authentication and authorization.
• Database users and permissions.
• Network exposure and private connectivity choices.
• Backup retention and restore requirements.
• Performance investigation and Query Store.
• Indexes, statistics and query design.
• Monitoring and alerts.
• Service tier, compute and storage sizing.
• Business continuity and regional resilience.
• Migration planning and compatibility.
• Cost and governance.

Backups feel different

Azure SQL Database automatically creates platform-managed backups, but the DBA still has to understand retention, point-in-time restore, long-term retention where required and what recovery options meet the business requirement. 'Azure handles backups' is not the same as 'recovery is no longer our responsibility.'

High availability becomes more service-oriented

Local high availability is built into the platform architecture. The DBA spends less time building Windows clusters and more time understanding service-tier resilience, zone redundancy where available, geo-replication, failover groups, RPO and RTO.

Security moves toward identity and network design

Azure SQL supports Microsoft Entra-based authentication and database permissions alongside other supported methods. The DBA needs to understand identity, firewall rules, private endpoints, auditing, encryption and the difference between Azure RBAC permissions and database permissions.

Monitoring changes tools, not principles

The principles remain familiar: establish a baseline, identify regressions, investigate waits and resource pressure, and compare before/after evidence. But the toolset includes Azure Monitor, service metrics, diagnostic settings and cloud-native alerting in addition to Query Store and database DMVs.

Capacity becomes service configuration

Instead of ordering hardware or expanding a physical SAN, the DBA may change service tiers, compute size, serverless settings, elastic pools or storage limits. Scaling can be faster, but cost becomes an explicit operational variable.

Some SQL Server features differ or are unavailable

Azure SQL Database shares a common SQL engine foundation with SQL Server, but server-level features and compatibility boundaries differ. A migration assessment should therefore identify dependencies such as SQL Server Agent jobs, cross-database behaviour, instance-level features, linked servers or other components that may influence target choice.

Why on-premises knowledge still helps

Understanding SQL Server security, recovery, transactions, execution plans, indexes, statistics and troubleshooting gives a DBA a strong foundation for cloud administration. The cloud service changes what you operate directly, not the underlying need to reason about data and workload behaviour. Explore Azure SQL administrator skills for more detail.

A simple comparison

• On-premises SQL Server: you manage the server and the database platform.
• SQL Server on Azure VM: Azure hosts the VM, but you still administer SQL Server much like a self-managed server.
• Azure SQL Managed Instance: more platform-managed, with broader instance-level compatibility.
• Azure SQL Database: highly managed database service with the smallest infrastructure footprint for the customer.

The DBA role becomes more architectural

Cloud DBAs spend more time choosing service models, designing secure connectivity, validating migration compatibility, monitoring cost and performance, and building recovery around managed capabilities. The job becomes less about server maintenance and more about operating the database service correctly. For a focused explanation, see Azure SQL service choices.

Related training

Hands-On Azure SQL Database Administration: Managed Databases & Cloud Operations is designed to build on SQL Server administration while teaching the operational differences introduced by managed Azure database services.

View the Azure SQL course

Need help choosing the right course?

If you are not sure where to begin, contact Goalbi Academy and tell us your current experience level and what you want to learn.

Contact Goalbi Academy

References

What Is Azure SQL? - Azure SQL

Compare SQL Database Engine Features - Azure SQL Database & Azure SQL Managed Instance

Microsoft Entra Authentication - Azure SQL Database & Azure SQL Managed Instance & Azure Synapse Analytics

Automatic, Geo-Redundant Backups - Azure SQL Managed Instance