After this lesson, you will be able to: Choose the right Azure database: Azure SQL Database for managed relational, Azure Database for PostgreSQL for open-source relational, and Cosmos DB for globally distributed NoSQL.
Azure's managed databases mirror the AWS lineup with a Microsoft flavor. Azure SQL Database is the managed relational workhorse; Azure Database for PostgreSQL serves teams that want open-source Postgres; and Cosmos DB is the globally distributed NoSQL service with multiple APIs and tunable consistency. Picking correctly, and configuring scale and consistency, is the same architecture decision you made on AWS, in Azure terms.
Azure SQL Database is a fully managed relational database built on the SQL Server engine: automated backups, patching, high availability, and scaling without managing a VM. It is the natural choice in Microsoft-heavy shops and for apps that already speak T-SQL. Azure Database for PostgreSQL (Flexible Server) is the managed open-source option, the same Postgres you used with Supabase and in the SQL subtrack, run by Azure with backups, HA, and read replicas. Both are the rough equivalents of AWS RDS. Choose by ecosystem and engine preference: T-SQL/.NET shops lean Azure SQL; teams standardized on Postgres pick the PostgreSQL service.
Cosmos DB is Azure's flagship NoSQL database: it replicates your data across any number of regions for low-latency global reads and writes, with single-digit-millisecond latency and SLA-backed availability. It speaks several APIs (Core/NoSQL document, MongoDB, Cassandra, Gremlin graph, Table), so you can often point existing MongoDB or Cassandra code at it. Its standout feature is five tunable consistency levels, from strong (always the latest write, higher latency) to eventual (fastest, may briefly read stale), letting you trade consistency for latency per workload. It is the rough analog of DynamoDB, with multi-region and multi-API as the differentiators.
Defaulting to Cosmos DB for relational data with joins; like DynamoDB, it shines for known access patterns, not ad-hoc relational queries. Leaving Cosmos DB on Strong consistency globally and paying in latency and request units when Session would serve the app fine. Over-provisioning request units (RUs) and getting a surprise bill; use autoscale and right-size to actual throughput. Choosing Azure SQL purely out of habit when the team and tooling are all Postgres, adding friction for no benefit. Putting a managed database in a public-facing subnet; keep it private and reachable only from the app tier (ties back to the networking lesson).
Pick the best fit.
Sign in and purchase access to unlock this lesson.