Azure Database Services Guide
Azure provides a comprehensive portfolio of managed database services designed to support nearly every data workload, from traditional relational applications to globally distributed NoSQL systems. Instead of requiring you to install, patch, and maintain database engines on virtual machines, Azure handles infrastructure operations so that engineering teams can focus on data modeling, query performance, and application logic.
This guide introduces the most important Azure database services, explains the architectural trade‑offs between them, and helps you select the right service for your workload. You will also find links to in‑depth articles for each service.
Database Service Categories
Azure organizes its database offerings into several broad categories that align with different data models and operational needs:
- Relational Databases – Engine‑based services that provide full SQL capabilities, strong consistency, and transactional guarantees. Ideal for structured data with well‑defined schemas and complex queries.
- NoSQL Databases – Services that support flexible, schema‑less data models and horizontal scaling. They excel at high‑volume, low‑latency workloads that do not require rigid table structures.
- In‑Memory Cache – Managed caching layers that reduce database load and improve response times for read‑heavy or session‑oriented workloads.
- Managed Database Platforms – Services that offer near‑complete compatibility with existing database engines (SQL Server, PostgreSQL, MySQL, Cassandra) while automating patching, backups, and high availability.
- Database Migration – Tools and services that simplify moving on‑premises databases to Azure with minimal downtime.
Choosing the Right Azure Database Service
Database selection should always be driven by your application’s requirements rather than product popularity. The table below maps common workload patterns to the most appropriate service.
| Requirement | Recommended Service |
|---|---|
| Traditional relational applications (OLTP) | Azure SQL Database |
| Enterprise SQL Server migration with minimal code changes | Azure SQL Managed Instance |
| Globally distributed, low‑latency NoSQL applications | Azure Cosmos DB |
| Open‑source PostgreSQL workloads requiring managed operations | Azure Database for PostgreSQL |
| Open‑source MySQL workloads for web or CMS applications | Azure Database for MySQL |
| Distributed caching, session state, and real‑time data | Azure Cache for Redis |
| Large‑scale, write‑heavy Cassandra workloads | Azure Managed Instance for Apache Cassandra |
| Database assessment, migration, and cutover | Azure Database Migration Service |
Beyond this simple mapping, you should also evaluate:
- Consistency model – Do you need strong ACID guarantees or is eventual consistency acceptable?
- Scaling pattern – Will you scale vertically (larger instances) or horizontally (more nodes, sharding)?
- Operational overhead – How much control do you want over versioning, patching, and performance tuning?
- Existing ecosystem – Are you locked into a specific engine due to tooling, extensions, or application code?
- Cost structure – Does your workload benefit from serverless compute, reserved capacity, or pay‑per‑request pricing?
Database service decision map
| Workload requirement | Primary service | Why it may fit | Important boundary |
|---|---|---|---|
| New cloud‑native relational app | Azure SQL Database, Azure Database for PostgreSQL, Azure Database for MySQL | Managed infrastructure, built‑in high availability, point‑in‑time restore | Engine‑specific features; choose based on your team’s SQL dialect and library ecosystem |
| Existing SQL Server app needing instance‑level features | Azure SQL Managed Instance | Near‑complete SQL Server surface area, SQL Agent, linked servers | Still requires compatibility assessment; not identical to on‑premises SQL Server |
| Globally distributed app with flexible schema | Azure Cosmos DB | Multi‑region writes, tunable consistency, document/graph/key‑value APIs | Partition key design is mandatory; cross‑partition queries can be expensive |
| High‑throughput key‑value or session caching | Azure Cache for Redis | Sub‑millisecond latency, data structures, pub/sub | Ephemeral data; not a durable system of record |
| Cassandra‑compatible workload | Azure Managed Instance for Apache Cassandra | Managed Cassandra with compatibility for existing tooling | Wide‑column modeling; eventual consistency by design; not a general NoSQL replacement |
| Database migration from on‑premises | Azure Database Migration Service | Guides assessment, online/offline migration for many sources | Not a database engine; handles movement, not schema transformation |
Core Database Services
Azure SQL Database (⭐⭐⭐⭐⭐)
Azure SQL Database is a fully managed platform‑as‑a‑service for cloud‑born applications. It provides automatic backups, point‑in‑time restore, active geo‑replication, and intelligent performance tuning. It is the default choice for new applications that can work within a single‑database model and do not need instance‑level features like SQL Agent or linked servers.
Best for: SaaS applications, modern transactional APIs, elastic pools for multi‑tenant architectures.
Does not replace: SQL Server features that require the instance boundary (e.g., cross‑database queries, certain system stored procedures). Complex migration from on‑premises may need Managed Instance.
Azure Cosmos DB (⭐⭐⭐⭐⭐)
Azure Cosmos DB is a globally distributed, multi‑model database service designed for applications that need single‑digit‑millisecond latencies, automatic scaling, and multi‑region writes. It supports document (SQL API), MongoDB API, Cassandra API, Gremlin (graph), and Table API, though the underlying engine is not a direct port of any single open‑source database.
Key design responsibilities:
- Partition key: The most critical design decision. A poorly chosen partition key causes hot partitions, throttling, and uneven distribution.
- Consistency model: Choose from five well‑defined consistency levels, from strong to eventual. Strong consistency incurs higher latency and cost.
- Request units (RUs): Throughput is provisioned in RU/s. Over‑provisioning wastes money; under‑provisioning causes rate limiting.
- Data modeling: You must model data for your query patterns. Embedding documents avoids joins but can lead to large documents; referencing requires cross‑partition queries.
Cosmos DB is not a drop‑in replacement for a relational database. It does not support arbitrary joins, server‑side transactions across documents, or schema enforcement in the same way. Applications must handle consistency conflicts in multi‑region setups.
Azure Cache for Redis (⭐⭐⭐⭐⭐)
Azure Cache for Redis provides a managed, open‑source‑compatible in‑memory data store. It is not a database of record; it accelerates access to data that lives elsewhere.
Typical use cases:
- Session state for horizontally scaled web apps.
- Database query result caching.
- Rate limiting and distributed locks (with caution).
- Pub/sub messaging for real‑time notifications.
What a cache does not replace: Durable storage, transactional consistency, long‑term persistence. A cache should always be treated as a volatile performance layer. Plan for cold starts, eviction, and invalidation.
Managed Open‑Source Databases
Azure Database for PostgreSQL (⭐⭐⭐⭐)
Azure Database for PostgreSQL is a fully managed, open‑source‑compatible database service that automates patching, backups, and high availability. It supports the full PostgreSQL ecosystem—extensions, advanced indexing, geospatial functions, and procedural languages—so teams can build on familiar tools while removing the operational burden of self‑hosted PostgreSQL.
Best for: enterprise applications that need a robust relational backend with strong data integrity, complex querying, and rich extensibility. It is the preferred Azure service for new PostgreSQL workloads and for migrating existing PostgreSQL systems to the cloud.
Important design considerations:
- Flexible Server is the recommended deployment model for production. It offers better cost control, zone‑redundant high availability, and finer‑grained configuration than the legacy Single Server.
- Extensions and versioning: not all extensions are supported in every PostgreSQL version. Verify compatibility before migration.
- Connection management: PostgreSQL uses a process‑per‑connection model, so heavy concurrent workloads need connection pooling (e.g., PgBouncer) to avoid resource exhaustion.
What a managed service does not replace: you still own schema design, query tuning, index maintenance, and access control. A managed PostgreSQL instance does not automatically fix slow queries or bad data models.
Azure Database for MySQL (⭐⭐⭐⭐)
Azure Database for MySQL is a fully managed MySQL database service that automates backups, patching, and scaling for applications built on the MySQL engine. It is compatible with the MySQL community edition and integrates with existing MySQL tools, drivers, and frameworks, making it a natural target for LAMP‑stack, CMS, and e‑commerce workloads moving to the cloud.
Best for: web applications, content management systems (WordPress, Drupal), e‑commerce platforms, and MySQL‑based applications that need a managed, highly available backend without re‑architecting the data layer.
Important design considerations:
- Flexible Server is the recommended model for production, offering better control over high availability, maintenance windows, and networking compared to Single Server.
- Storage engine: InnoDB is the default and recommended storage engine; MyISAM support is limited. Verify engine compatibility before migration.
- Connection limits: MySQL server connection limits can be a bottleneck; use connection pooling in the application to avoid exhausting connections.
What a managed service does not replace: you remain responsible for schema design, query optimization, and application‑level access control. A managed MySQL instance does not eliminate the need for proper indexing or connection management.
Azure SQL Managed Instance (⭐⭐⭐⭐)
Managed Instance provides a broader SQL Server surface area with near‑complete compatibility, including SQL Agent, database mail, and linked servers. It runs in your own VNet, making it a preferred target for lift‑and‑shift migrations that cannot be refactored for Azure SQL Database.
Best for: Migrating legacy SQL Server applications with minimal code changes, workloads needing instance‑level features.
Important: Always run the Data Migration Assistant before committing. Not all features are supported; some T‑SQL behaviors differ.
Specialized Database Services
Azure Database Migration Service (⭐⭐⭐)
Azure Database Migration Service (DMS) automates the movement of databases from on‑premises or other clouds to Azure. It supports scenarios for SQL Server, PostgreSQL, MySQL, and MongoDB to various Azure targets. DMS handles the replication engine; you still must address schema incompatibilities, user accounts, and application connection strings.
DMS is a migration tool, not a database engine. It does not fix application issues, optimize queries, or manage long‑term operations.
Azure Managed Instance for Apache Cassandra (⭐⭐⭐)
This service provides a managed, compatible environment for existing Cassandra applications. It supports the Cassandra Query Language (CQL) and the same ring‑based, masterless architecture. Use it when your application is already built on Cassandra and you want to offload operational overhead.
Not a general‑purpose NoSQL: Cassandra excels at write‑heavy, partition‑tolerant workloads with simple key‑based queries. It is not designed for ad‑hoc analytical queries or complex joins.
Azure Database for PostgreSQL Flexible Server Advanced Features (⭐⭐⭐)
This page explores the deeper operational capabilities available in the PostgreSQL Flexible Server deployment model. Once you have chosen PostgreSQL as your engine and Flexible Server as your deployment model, these features help you fine‑tune availability, performance, and recoverability for production workloads.
Key capabilities covered:
- High‑availability configurations: zone‑redundant deployments that survive the loss of a complete availability zone, plus automatic failover with zero data loss for synchronous replication.
- Read replicas: offload analytical queries or reporting workloads to read‑only replicas, which can be promoted to primary in a disaster‑recovery scenario.
- Performance tiers: burstable instances for variable workloads and premium‑managed disks for consistent, high IOPS.
- Intelligent performance tuning: automated index recommendations and query performance insights to identify slow queries and missing indexes.
Boundary: this page does not replace the general PostgreSQL service overview; it assumes you already understand the core service and are ready to implement advanced operational controls.
Legacy Services
Azure Database for MariaDB (⭐)
Azure Database for MariaDB is a legacy managed database service that provided compatibility with the MariaDB open‑source engine. Microsoft has announced the retirement of this service. No new deployments should be created. Existing workloads should be migrated to Azure Database for MySQL (the closest compatible engine) or Azure Database for PostgreSQL.
If you have an existing MariaDB deployment:
- Assess compatibility with MySQL using tools like MySQL Workbench or the MariaDB Migration Guide.
- Choose online or offline migration via Azure Database Migration Service.
- Test application behavior thoroughly, as minor SQL syntax and storage engine differences may exist.
Best Practices
- Prefer managed databases over self‑managed VMs. Managed services reduce patching, backup, and high‑availability effort, allowing your team to focus on data and application design.
- Match the data model to the workload. Do not force a relational model onto document‑oriented data, and do not try to run complex transactions on a key‑value store.
- Separate transactional and analytical workloads. Use operational databases for OLTP and dedicated analytical platforms (e.g., Azure Synapse, Microsoft Fabric) for heavy reporting and data warehousing.
- Plan backup and disaster recovery from day one. Managed databases provide automated backups, but you must verify restore procedures and define your recovery point objective (RPO) and recovery time objective (RTO).
- Use caching where it adds value, but treat it as a volatile layer. A cache should accelerate access to a durable system of record, not replace it.
- Monitor performance continuously. Use Azure Monitor, Query Performance Insight, and database‑specific metrics to detect slow queries, deadlocks, and resource pressure.
- Design for scale before you need it. Understand the scaling limits of your chosen service—whether vertical, horizontal, or shard‑based—and test realistic workloads.
Common database architecture anti‑patterns
- Choosing a database by popularity, not by workload. Always map data model, access patterns, and consistency requirements to the service.
- Treating Azure SQL Database and Managed Instance as interchangeable. Instance‑level features matter; use Managed Instance only when needed.
- Using Cosmos DB without designing partition keys. A missing or poor partition key leads to hot partitions and throttling.
- Using a cache as the source of truth. Caches are volatile; always persist data in a durable store and treat the cache as a performance layer.
- Assuming that managed means no operations. You still own schema design, query tuning, access control, and backup verification.
- Using replication as a backup. Replication does not protect against accidental data deletion or corruption; scheduled, tested backups do.
- Ignoring connection pooling. Opening a new connection per request exhausts database resources and increases latency.
- Storing credentials in code or config files. Use managed identities and Key Vault; eliminate static secrets.
- Running analytical queries on the operational database without isolation. This can impact transactional performance; use read‑only replicas or a dedicated data warehouse.
Representative architecture scenario: multi‑tenant SaaS backend
Consider a SaaS application that serves multiple customer tenants, each with isolated data. The backend consists of:
- Stateless API servers (Azure App Service or Container Apps) that authenticate users via Microsoft Entra External ID.
- Azure SQL Database using elastic pools to host many tenant databases efficiently.
- Azure Cache for Redis to store session state and hot query results.
- Azure Blob Storage for tenant file uploads.
- Azure Database Migration Service was used during the initial migration from on‑premises SQL Server to Azure SQL Managed Instance for the legacy monolith, followed by a refactor into the elastic‑pool model.
- Monitoring via Azure Monitor and Application Insights tracks query latency, deadlocks, and Redis cache hit ratios.
Why this design? Relational data with strong tenant isolation fits Azure SQL Database’s elastic pools. The cache offloads repeated reads, and the migration path allowed a phased modernization. Cosmos DB was rejected because tenants required complex relational queries and transactions across multiple tables. The operational team validates backup restore monthly and performs geo‑restore drills annually.
When would this change? If a new tenant workload required a flexible schema and global distribution, a separate Cosmos DB collection could be added for that tenant, with clear separation of transactional and analytical responsibilities.
Operations and lifecycle
Database management continues well after deployment. Establish practices for:
- Version upgrades and patch management (automated where possible).
- Schema change management using migrations tools and CI/CD pipelines.
- Capacity monitoring: storage growth, connection counts, and throughput.
- Regular backup restoration tests.
- Disaster recovery drills that include application‑level failover.
- Quarterly access reviews: remove unused logins, rotate service principal credentials.
- Cost governance: identify idle resources, consolidate elastic pools, and rightsize.
Related Azure Services
Databases rarely operate in isolation. The following services are commonly used alongside Azure database offerings:
- Azure Virtual Machines – For workloads that require custom database engine configurations not supported by managed services.
- Azure Blob Storage – For storing large binary objects, backups, and data lake ingestion.
- Azure Data Factory – For orchestrating data movement and transformation between databases.
- Azure Monitor – For collecting metrics, logs, and alerts across the database estate.
- Azure Key Vault – For securely storing connection strings, encryption keys, and secrets used by databases.
- Microsoft Fabric – For unified analytics and business intelligence on top of operational data.