Database Reference Architectures
Production-proven HA cluster topologies, consensus-backed failover models, quorum mechanisms, and reference configs with dedicated single-page blueprints.
PostgreSQL + Patroni + etcd + HAProxy Enterprise HA
Distributed consensus-backed HA topology using etcd to eliminate split-brain hazards and guarantee sub-15s automatic failover.

- •Automated failover & split-brain immunity
- •Dynamic cluster configuration
- •Graceful zero-data-loss switchover for maintenance
- •Requires minimum 3-node quorum
- •Higher infrastructure and networking complexity
MySQL InnoDB Cluster + Group Replication + MySQL Router Topology
Native MySQL high-availability architecture driven by Paxos group replication protocol. Runs in single-primary mode to eliminate write conflicts and routes traffic transparently via MySQL Router.

- •Official native MySQL solution
- •No external consensus daemon required
- •Streamlined cluster management via MySQL Shell API
- •Minimum 3 node quorum requirement
- •Strict requirement for InnoDB tables and primary keys
SQL Server Always On Availability Groups (AG) Topology
Database-level high availability and disaster recovery with readable secondary replicas to offload reporting queries.

- •Read-only workload offloading
- •No shared storage (SAN) single-point-of-failure
- •Fast automated failover with AG Listener
- •Enterprise edition licensing costs
- •WSFC cluster quorum sensitivity
PostgreSQL pgvector HNSW: Production RAG Blueprint & Tuning Guide
Deploy and scale pgvector HNSW safely in production: maintenance_work_mem sizing, WAL generation, Patroni replication, lock mitigation, hybrid search, and diagnostic queries.

- •Eliminates dedicated vector database licensing and dual-write reconciliation overhead
- •Guarantees ACID consistency by keeping relational records and vector embeddings in identical transactions
- •Leverages pgvector 0.8.x iterative scan and halfvec for optimal RAM, CPU, and cache residency
- •Graph construction demands substantial maintenance_work_mem and heavy WAL throughput
- •High WAL volume can elevate primary commit latencies in synchronous replication topologies
- •Non-HOT updates trigger index bloat and degrade ef_search candidate recall