Azure offers managed relational, document, key-value, cache, and analytics data services. Selection begins with data shape, query patterns, consistency, scale, and recovery needs.
Azure SQL Database and managed open-source engines support relational workloads. Cosmos DB supports globally distributed NoSQL models, while managed cache reduces repeated reads when cached data can be rebuilt.
Managed databases reduce infrastructure work but still require private access, credential design, capacity planning, backups, monitoring, and tested recovery.
Use relational services when transactions, joins, constraints, and SQL are central. Consider Cosmos DB when partitioned access patterns and global distribution are explicit requirements.
Use Microsoft Entra authentication where supported, store remaining secrets in Key Vault, and connect through private endpoints or delegated subnets according to the service.
Define required availability, recovery point, and recovery time before selecting redundancy or geo-replication. Restore backups into an isolated environment and validate application-level correctness.
Monitor latency, CPU or request units, storage, connections, locks, throttling, and failed requests. Pair platform metrics with query plans and application traces.
List required reads, writes, joins, filters, ordering, transactions, consistency, throughput, item size, latency, retention, growth, and regional behavior before selecting a service. Include backup, export, audit, and deletion. A managed product name cannot compensate for a data model that does not fit the application operations.
Azure SQL and Azure Database for PostgreSQL provide relational engines with constraints and transactions. Azure Cosmos DB supports distributed data models and APIs with partitioned throughput and selectable consistency. Azure Managed Redis provides in-memory data structures and caching behavior. Each moves different infrastructure work to Microsoft and leaves different application responsibilities.
Record rejected options, engine compatibility, migration tooling, operator skill, lock-in, and recovery. Benchmark production-like data and concurrency. Database choice is an application contract that affects code, cost, and failure for years.
Azure SQL Database provides managed SQL Server database capabilities with purchasing and service tiers that differ in compute, storage, I/O, scaling, replicas, and recovery. Azure SQL Managed Instance offers broader instance compatibility for migrations with instance-level features. Verify feature and version compatibility rather than assuming every SQL Server workload fits either service unchanged.
Choose provisioned or serverless compute and General Purpose, Business Critical, Hyperscale, or current supported alternatives from workload behavior. The tier affects architecture, not only price. Test connection limits, temp workload, transaction log behavior, read scale, maintenance, and scale operations with production-like queries.
Use Entra authentication where it fits, private endpoints or controlled firewall paths, TLS validation, and contained least-privilege database users. Add transient-fault retry at safe transaction boundaries. Zone and geo-redundancy improve availability, while backups and point-in-time restore protect logical error.
Azure Database for PostgreSQL Flexible Server manages infrastructure, backups, patch workflow, and supported high-availability configurations while the customer owns schema, queries, extensions, roles, connections, and application compatibility. Verify extension, collation, parameter, major version, and Region support before migration.
Zone-redundant and same-zone high availability use a synchronously replicated standby under the service model, but availability is not backup. A standby can receive the same accidental deletion. Use point-in-time restore for logical error and test it into a separate server before promoting or extracting data.
Bound application connection pools across the whole fleet, reserve operational capacity, and consider an appropriate pooler. Monitor CPU, memory, storage, I/O, connections, transaction age, locks, query latency, replication, backup, and maintenance. Test planned and unplanned failover and application reconnection.
Azure Cosmos DB distributes items by a partition key into logical partitions that map to service-managed physical partitions. Choose a high-cardinality key that distributes storage and request units while appearing in common queries. A hot key can constrain one logical partition even when total account capacity looks sufficient.
Model request-unit cost for point reads, queries, writes, indexing, and cross-partition work. Select indexing paths and throughput mode from measured access. Transactions and stored procedures have partition boundaries under the selected API. A broad cross-partition query may work in a lab but scale poorly in latency and cost.
Choose strong, bounded staleness, session, consistent prefix, or eventual consistency from application semantics and regional design. Session consistency depends on session-token handling for read-your-write behavior. Multi-region writes introduce conflict and routing decisions that must be tested during failover.
Use Azure Managed Redis for caches and supported in-memory data patterns whose loss, eviction, and staleness are understood. Azure Cache for Redis has a retirement path, so new and existing designs must follow current Microsoft migration guidance rather than treating old tiers as the long-term default.
Define source of truth, cache-aside or write strategy, TTL, invalidation, key ownership, serialization version, and stampede protection. Add jitter to synchronized expiry and prevent an empty cache from overwhelming the database. A successful cache write is not a durable business commit unless the architecture explicitly makes it one.
Use private networking, Entra or supported authentication, TLS, and secret rotation according to the selected service. Monitor hit ratio, latency, memory, eviction, connections, server load, replication, and source impact. Exercise cache flush, node failover, stale values, and migration to a new instance.
Use versioned expand-and-contract schema changes for rolling application releases. Estimate lock, rewrite, index build, and backfill cost against production-like data. Keep backfills resumable and rate-limited, and define whether rollback reverses data, stops a writer, or rolls forward with correction.
Place database endpoints on private paths where required, validate TLS, manage credentials or Entra identities centrally, and separate deployment from runtime privilege. Plan DNS and connection retry for failover without retrying an uncertain non-idempotent transaction blindly.
Map every data store to RPO and RTO, backup retention, key ownership, regional copy, and restore owner. Restore into isolation and verify schema, users, network, integrity, and real application reads and writes. Monitor performance and recovery evidence continuously; a completed backup job is not proof that the business can recover.
Track engine major versions, service-tier changes, retired SKUs, authentication methods, network features, drivers, extensions, backup behavior, and cache retirement notices. A managed database reduces infrastructure maintenance but does not make an unsupported application driver or extension compatible automatically.
Test upgrades and migrations with production-like schema, statistics, workload, connection pools, failover, private DNS, encryption, and restore. Keep a rollback or forward-fix plan for data changes, and finish the migration before the service deadline removes a safe rehearsal window.
Set connection, command, and transaction timeouts from the outer request deadline. Retry transient connection or availability failures with bounded jitter only when the operation is safe; never replay an ambiguous committed write without an idempotency or reconciliation rule. Pool limits must account for every app replica, function host, worker, and administrative reserve.
During failover, DNS, existing sockets, transactions, session state, and prepared work can behave differently. Test driver reconnection against Azure SQL, PostgreSQL, Cosmos DB, or Redis according to the selected service. Record which errors are transient, which require rollback, and what the user sees while the client recovers.
CREATE TABLE Orders (
Id INT IDENTITY PRIMARY KEY,
CustomerEmail NVARCHAR(255) NOT NULL,
TotalAmount DECIMAL(10,2) NOT NULL,
CreatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME()
);
CREATE INDEX IX_Orders_CustomerEmail ON Orders(CustomerEmail);A faulty migration removes rows from a production database.
Constraints: The recovery point objective is ten minutes and the original server must remain available for comparison.
Decision: Restore to a new database just before the migration, validate invariants, then choose a controlled cutover or selective repair.
Verification: Row counts, checksums, permissions, and application smoke tests pass within the recovery objective.
Failure test: Restore from an older point and show the validation rejects missing legitimate transactions.Expected evidence: Row counts, checksums, permissions, and application smoke tests pass within the recovery objective.Explore 500+ free tutorials across 20+ languages and frameworks.