Managed Databases on Azure

Every option above supports a public endpoint gated by an IP/service-tag firewall (quick to set up, fine for development) and a private endpoint — a network interface with a private IP inside your own virtual network, backed by Azure Private Link — for production traffic that should never cross the public internet. Elastic Cloud and Marketplace SaaS options (MongoDB Atlas, Redis Cloud, Couchbase Capella, Neo4j AuraDB, Qdrant Cloud) typically expose their own private-link equivalent rather than an Azure-native private endpoint; check the specific product’s networking page before assuming parity with a first-party service.

Azure SQL Database/Managed Instance, PostgreSQL and MySQL flexible server, and Azure DocumentDB/Cosmos DB all support authenticating client connections with Entra ID identities (a user, group, or managed identity) instead of a database-local username/password, so the same role-based access review that governs the rest of a subscription also governs who can connect. Marketplace SaaS and self-managed-on-AKS options generally do not integrate with Entra ID for the data-plane connection itself — they authenticate with their own users/API keys, though Entra ID can still gate the Azure resource (the AKS cluster, the Marketplace resource) that fronts them.

First-party PaaS options take automatic backups on a retention window you configure and support restoring to a new instance at an arbitrary point in time within it (PITR). Self-managed engines on AKS/VMs need their own backup tooling (a cron job driving the engine’s native dump/snapshot mechanism, or an operator’s built-in backup CRD) — there is no PITR for free.

Zone-redundant HA (synchronous replicas across three availability zones, automatic failover) is available as a tier or an add-on flag on Azure SQL Database/Managed Instance, PostgreSQL/MySQL flexible server, and Azure DocumentDB/Cosmos DB. On AKS, the equivalent is spreading an engine’s own replica set or cluster nodes across zones with pod anti-affinity and a zonal node pool — the platform gives you the zones, the engine’s own clustering does the rest.

Azure SQL, PostgreSQL/MySQL flexible server and Azure DocumentDB/Cosmos DB all support cross-region read replicas for read scaling and disaster recovery; Redis (Managed Redis and Cache for Redis) supports active geo-replication for multi-region active-active workloads. Cross-engine, this is the same replication concept covered in depth on each engine’s own reference page under this site’s Database Development section.

First-party PaaS options scale compute (vCores) and storage independently and mostly online, with flexible server and Azure SQL both offering a serverless/auto-pause tier for spiky or dev/test workloads. On AKS, scaling means resizing the node pool and the engine’s own StatefulSet/operator-managed replica count — see AKS Clusters for the cluster-level mechanics.

PaaS options apply platform patching and minor-version upgrades inside a maintenance window you can schedule (a day-of-week/time-of-day pair) so that patching does not land during peak traffic; a self-managed AKS deployment is your own responsibility to patch, on your own schedule.

Whichever option you pick, application code should read its connection string/credentials from Key Vault rather than from a config file or an environment variable checked into source control — see Key Vault and Secrets for storing and rotating the secret itself, and Identity and Access for granting the application’s managed identity read access to it.