Azure SQL / PostgreSQL Flexible

Managed relational databases.

Problem it solves: Most business data needs integrity constraints and transactions.

Where it sits: Behind services (and their cache).

When to use

  • Default for OLTP data with relationships and transactions.

When not to use

  • Write volumes beyond one primary without a sharding plan.

Failure modes

  • Primary saturation on writes.
  • Replication lag causes stale reads on replicas.
  • Primary failure without automated failover.

Metrics to watch

  • Read/write QPS
  • CPU (%)
  • Replication lag (s)
  • Slow queries

Alternatives

  • Key-value / wide-column store
  • NewSQL

Configuration in Labs (illustrative defaults)

  • Capacity per instance (req/s) = 5000 — Maximum requests one instance completes per second before it saturates.
  • Write capacity (primary) (writes/s) = 2000 — Writes the single primary can absorb per shard. Replicas do not add write capacity.
  • Read replicas (count) = 1 — Each replica adds one instance of read capacity. Replication lag is not modelled numerically.
  • Shards (count) = 1 — Partitions; each multiplies read and write capacity assuming keys spread evenly (no hot key).
  • Base service time (ms) = 5 — Processing time per request at zero load. Queueing adds to this as utilisation rises.

Vendor examples (pattern only): Azure managed service. Simulated as a generic “Relational database”.

In the guide