Replication

Where it shows up in real systems

• Relational database

  The primary handles every write; read replicas add read capacity but lag slightly behind, so a user may not see their own write. A Multi-AZ standby takes over in about a minute if the primary fails. Sharding multiplies write capacity, but a bad shard key creates a hot shard. Without connection pooling, many app instances exhaust the connection limit.

  In production: PostgreSQL (Amazon RDS, Aurora), MySQL, Azure SQL Database, Cloud SQL, Citus, Vitess

• Document database

  A replica set elects a new primary when the current one fails. With write concern majority, an acknowledged write survives that failover; with w:1, recent writes can be rolled back. Reading from secondaries scales reads but returns slightly stale data.

  In production: MongoDB Atlas, Amazon DocumentDB, Couchbase, Firestore

• Graph database

  Traversing relationships is fast even several hops deep, where the same query in SQL would need many joins. Graphs are hard to shard, so they usually scale reads with replicas.

  In production: Neo4j, Amazon Neptune, TigerGraph, ArangoDB

• Vector database

  Powers semantic search, recommendations and retrieval for AI assistants. Approximate nearest-neighbour indexes such as HNSW trade a little recall for huge speed; they live mostly in memory, so size nodes by the number of vectors.

  In production: pgvector, Pinecone, Weaviate, Milvus, Qdrant, OpenSearch k-NN