ServerlessBase Blog

    • Galera Cluster vs PostgreSQL Cluster: Comparison

    A comprehensive comparison of Galera Cluster and PostgreSQL clustering approaches for high availability and synchronous replication.

    postgresqldatabasehigh-availabilityclusteringsynchronous-replication

    Galera Cluster vs PostgreSQL Cluster: Comparison

    You've probably faced the classic database problem: your application needs high availability, but a single PostgreSQL instance is a single point of failure. You start researching clustering solutions and immediately hit two competing options: Galera Cluster and traditional PostgreSQL clustering. Both promise synchronous replication and automatic failover, but they work very differently under the hood.

    This guide breaks down the differences between these approaches so you can choose the right strategy for your workload.

    Understanding PostgreSQL Clustering Approaches

    Before diving into specifics, it helps to understand the two fundamental approaches to PostgreSQL clustering:

    1. Synchronous replication clusters - All writes must be acknowledged by all replicas before the client receives success. Guarantees data consistency but adds latency.

    2. Asynchronous replication clusters - Writes are acknowledged immediately after being written to the primary database. Faster but can lose data during failover.

    Both Galera Cluster and traditional PostgreSQL clustering fall into these categories, but they implement them differently.

    Galera Cluster: Multi-Master Synchronous Replication

    Galera Cluster is a synchronous multi-master replication solution for PostgreSQL. It uses a write-set replication protocol to propagate changes across all nodes in the cluster.

    How Galera Works

    Galera introduces a write-set replication layer on top of PostgreSQL. When a transaction is committed on one node, Galera captures the write-set (the changes made by the transaction) and broadcasts it to all other nodes. Each node applies the write-set and confirms completion before the original transaction is considered committed.

    This approach enables true multi-master replication - any node can accept writes, and all changes are synchronized across the cluster.

    Key Features

    FeatureDescription
    Synchronous replicationAll nodes must acknowledge writes
    Multi-masterAny node can accept writes
    Automatic node joiningNew nodes can join without downtime
    Automatic node removalFailed nodes are automatically detected and removed
    Conflict resolutionLast write wins with configurable strategies
    No separate primaryNo need to elect a primary node

    Galera Cluster Architecture

    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Node 1    │◄────│   Node 2    │◄────│   Node 3    │
│  (Primary)  │     │  (Primary)  │     │  (Primary)  │
└─────────────┘     └─────────────┘     └─────────────┘
       ▲                 ▲                 ▲
       │                 │                 │
       └─────────────────┴─────────────────┘
                   Galera WSREP

    All nodes communicate through the Galera Write Set Replication (WSREP) protocol, maintaining a consistent state across the cluster.

    Traditional PostgreSQL Clustering: Streaming Replication

    Traditional PostgreSQL clustering typically uses streaming replication with a primary/replica architecture. This is the approach used by PostgreSQL's built-in replication features and tools like Patroni, Repmgr, and PgBouncer.

    How Streaming Replication Works

    In streaming replication, you have a primary database that accepts writes and one or more replicas that receive a copy of the WAL (Write-Ahead Log). Replicas continuously stream WAL records from the primary.

    Writes are asynchronous - the client receives success immediately after the primary acknowledges the transaction. Replicas apply the WAL records in the background.

    Key Features

    FeatureDescription
    Asynchronous replicationWrites are acknowledged immediately
    Primary/replica modelOnly the primary accepts writes
    Manual failoverRequires intervention to promote a replica
    No automatic node joiningAdding nodes requires downtime or complex setup
    No conflict resolutionNo built-in mechanism for concurrent writes

    Streaming Replication Architecture

    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Primary   │────►│   Replica 1  │────►│   Replica 2  │
│  (Writes)   │     │  (Reads)    │     │  (Reads)    │
└─────────────┘     └─────────────┘     └─────────────┘
       ▲
       │
       └─────────────────────────────────────────┘
                   WAL Streaming

    The primary node is the only source of truth for writes. Replicas are read-only and must be promoted manually during failover.

    Direct Comparison: Galera vs Streaming Replication

    Multi-Master Capabilities

    Galera Cluster:

    • True multi-master - any node can accept writes
    • No need to manage a primary node
    • Automatic failover without manual intervention
    • All nodes stay in sync

    Streaming Replication:

    • Single primary model - only one node accepts writes
    • Manual failover required
    • Primary can fail without automatic promotion
    • Replicas are read-only

    If your application requires write scalability or automatic failover without human intervention, Galera Cluster is the clear winner.

    Data Consistency Guarantees

    Galera Cluster:

    • Strong consistency - all nodes see the same data
    • Synchronous replication ensures no data loss
    • Guarantees that all writes are visible to all nodes

    Streaming Replication:

    • Eventual consistency - replicas may lag behind primary
    • Asynchronous replication means data loss possible during failover
    • No guarantee that all replicas have the same data

    For applications requiring strong consistency, Galera Cluster provides better guarantees.

    Performance Impact

    Galera Cluster:

    • Synchronous replication adds latency - all nodes must acknowledge writes
    • Write performance is lower than streaming replication
    • Network bandwidth usage is higher due to write-set replication
    • Locking overhead for concurrent writes

    Streaming Replication:

    • Asynchronous replication has minimal impact on write performance
    • Primary node performance is not affected by replicas
    • Lower network bandwidth usage
    • No locking overhead for concurrent writes

    If write performance is critical and you can tolerate eventual consistency, streaming replication is faster.

    Operational Complexity

    Galera Cluster:

    • Simpler failover - any node can become primary
    • Automatic node management - failed nodes are removed
    • No need to manage a separate HA solution
    • Requires Galera-specific configuration

    Streaming Replication:

    • More complex failover - requires Patroni, Repmgr, or similar tools
    • Manual intervention often required for failover
    • Requires additional tools for high availability
    • More moving parts to manage

    Galera Cluster simplifies operations by handling failover automatically. Streaming replication requires additional tools to achieve similar high availability.

    Scalability

    Galera Cluster:

    • Limited write scalability - all nodes must process writes
    • Write scalability is limited by the slowest node
    • Good for read scalability - any node can serve reads
    • Not ideal for high-write workloads

    Streaming Replication:

    • Excellent write scalability - only primary handles writes
    • Read scalability is excellent - replicas can handle reads
    • Can scale reads horizontally
    • Ideal for high-write workloads

    For applications with high write throughput, streaming replication scales better. For read-heavy workloads, both approaches work well.

    Compatibility

    Galera Cluster:

    • Requires Galera library integration
    • Some PostgreSQL features are not supported
    • Requires specific storage engine (e.g., pluggable storage)
    • Not all extensions work with Galera

    Streaming Replication:

    • Native PostgreSQL feature
    • All PostgreSQL features work
    • No special storage engine required
    • All extensions work normally

    Streaming replication is more compatible with existing PostgreSQL setups and features.

    When to Choose Galera Cluster

    Choose Galera Cluster when:

    • You need automatic failover without manual intervention
    • Your application requires multi-master capabilities
    • Strong consistency is critical
    • You want to simplify operations by eliminating the need for HA tools
    • You have a read-heavy workload
    • You want to avoid single points of failure

    Galera Cluster is ideal for applications where availability and consistency are more important than raw write performance.

    When to Choose Streaming Replication

    Choose streaming replication when:

    • Write performance is critical
    • You can tolerate eventual consistency
    • You want to use all PostgreSQL features and extensions
    • You have a high-write workload
    • You prefer a simpler, more compatible solution

    Streaming replication is ideal for applications where performance and compatibility are more important than automatic failover.

    Practical Example: Setting Up Galera Cluster

    Here's how to set up a Galera Cluster with three nodes:

    # Install required packages
sudo apt-get update
sudo apt-get install -y galera-3 postgresql-12
 
# Configure the first node
sudo nano /etc/postgresql/12/main/galera.conf

    Add the following configuration:

    [galera]
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="my_cluster"
wsrep_cluster_address="gcomm://node1,node2,node3"
wsrep_node_name="node1"
wsrep_node_address="192.168.1.10"
 
[client]
port = 5432
host = localhost

    Start the cluster:

    # Initialize the cluster on the first node
sudo galera_new_cluster
 
# Start the service on other nodes
sudo systemctl start postgresql

    Verify the cluster status:

    sudo psql -U postgres -c "SELECT * FROM pg_stat_replication;"

    Practical Example: Setting Up Streaming Replication with Patroni

    Here's how to set up streaming replication with Patroni for automatic failover:

    # Install Patroni and etcd
sudo apt-get install -y patroni etcd
 
# Configure Patroni
sudo nano /etc/patroni/patroni.yml

    Add the following configuration:

    scope: postgres-cluster
name: node1
restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.10:8008
etcd3:
  hosts:
    - 192.168.1.10:2379
    - 192.168.1.11:2379
    - 192.168.1.12:2379
postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.10:5432
  data_dir: /var/lib/postgresql/12/main
  authentication:
    replication:
      username: replicator
      password: replicator_password
  parameters:
    max_wal_senders: 10
    max_replication_slots: 10
    hot_standby: on

    Start Patroni:

    sudo systemctl start patroni

    Patroni will automatically manage the primary/replica setup and handle failover.

    Conclusion

    Choosing between Galera Cluster and PostgreSQL streaming replication depends on your priorities:

    • Galera Cluster offers automatic failover, multi-master capabilities, and strong consistency at the cost of write performance and some compatibility limitations. It's ideal for applications where availability and consistency are critical.

    • Streaming replication provides better write performance, full PostgreSQL compatibility, and simpler setup, but requires manual intervention for failover and doesn't support multi-master writes.

    For most production workloads, streaming replication with a high availability solution like Patroni offers the best balance of performance, compatibility, and reliability. However, if automatic failover and multi-master capabilities are essential, Galera Cluster is worth the performance tradeoff.

    If you're using a platform like ServerlessBase, both approaches can be implemented with managed database services that handle the complexity of clustering and replication for you.

    Leave comment