Bucardo PostgreSQL Multi-Master Replication - AI Technical Reference

What Bucardo Is

Primary Function: Table-based PostgreSQL replication system enabling true multi-master setups
Operational Reality: Only mature PostgreSQL multi-master solution that doesn't corrupt data
Active Since: 2007 (18+ years production use)
Current Status: Version 5.6.0 (February 2020) - stable but quiet development
License: BSD (free commercial/non-commercial use)

Critical Architecture Details

Trigger-Based Implementation

• Mechanism: Installs triggers on every replicated table
• Performance Impact: 10-30% write performance degradation (every write hits database twice)
• Benefits: Captures ALL changes (including rolled-back transactions), enables row/column filtering
• Breaking Point: Complex indexed tables see worse than 30% degradation

Network Resilience

• Behavior: Queues changes during outages, processes backlog on reconnection
• Failure Mode: 3-day outage = 50GB queue = hours of catch-up processing
• Propagation Speed: 1-2 seconds under normal network conditions

Resource Requirements

System Prerequisites

• Perl: 5.8.3+ with DBI and DBD::Pg modules
• Critical Dependency: DBIx::Safe module (frequently breaks during install)
• PostgreSQL: 8.2+ with PL/pgSQL and PL/Perl enabled
• Platform: Linux/Unix only (no Windows daemon support)
• Dedicated Database: Required for Bucardo control schema

Real Setup Timeline

• Day 1: Fight Perl dependencies, DBIx::Safe installation failures, config syntax
• Day 2: Debug trigger permissions, connection strings, basic replication
• Production Ready: 2-3 days minimum for experienced teams

Configuration That Works

Multi-Master Deployment

• Sweet Spot: 2-5 databases per daemon
• Scaling: Separate daemons for different regions/table groups
• Geographic Distribution: Regional daemons for local database communication

Conflict Resolution Strategies

• bucardo_latest: Last write wins (requires synchronized clocks)
• bucardo_source: Source always wins (master-slave scenarios)
• Custom Functions: PL/pgSQL functions for business-specific logic
• Reality Check: Conflicts occur more frequently than anticipated

Critical Warnings

What Official Documentation Doesn't Tell You

• DDL Replication: Does not work - manual DDL execution required on all nodes
• Performance: API response times can double without proper planning
• Conflicts: Will happen more than expected - test with realistic concurrent loads
• Error Messages: Unhelpful ("something went wrong" level)
• Daemon Stability: Expect random segmentation faults with no stack trace

Production Failure Modes

• Large Backlogs: Stale replicas for hours during catch-up
• Trigger Overhead: Complex workloads see >30% performance hit
• Network Partitions: Queue buildup during extended outages
• Version Compatibility: Half of online examples are for v4.x (non-functional)

Versus Alternatives Comparison

Feature	Bucardo	PostgreSQL Logical	pglogical	Spock/pgEdge
Multi-Master	Production proven	Marketing only	Non-existent	Works but expensive
Version Support	8.2+ to latest	10+ only	9.4+ to latest	10+ to latest
Setup Complexity	High (2-3 days)	Low	High	Very High
When Breaks	Mailing list	No support	Paid support	Expensive support
DDL Sync	Manual only	Sometimes works	Partial	Full (paid)

Recommended Use Cases

Primary Success Scenarios

1. Zero-downtime migrations: Sync old/new PostgreSQL versions
2. Geographic distribution: Cross-datacenter synchronization
3. Legacy integration: Connect ancient PostgreSQL with modern versions
4. Development environments: Production-accurate test data

Anti-Patterns

• Load balancing writes: Conflict management complexity outweighs benefits
• High-frequency OLTP: Trigger overhead kills performance
• DDL-heavy applications: Manual schema changes across nodes

Production Monitoring Requirements

Critical Metrics

• Queue Depth: Growing queue = falling behind replica
• Conflict Rates: High rate = business logic problems
• Daemon Restarts: Frequency indicates stability issues
• Sync Lag: Actual replica freshness measurement

Support Resources

• Primary Support: Mailing list (bucardo-general)
• Professional Support: End Point Dev (original developers)
• GitHub: Issues redirected to mailing list
• Documentation: Comprehensive but dry, examples often outdated

Implementation Reality

When to Choose Bucardo

• Need proven multi-master (18+ years production)
• Cross-version replication requirements
• Table-level replication control needed
• Zero-downtime migration projects

When to Avoid

• Single-master scenarios (use built-in replication)
• High-performance OLTP requirements
• DDL-heavy applications
• Windows-only environments

Success Factors

• Plan for 10-30% write performance impact
• Budget 2-3 days for initial setup
• Test conflict scenarios with realistic loads
• Implement comprehensive monitoring
• Prepare for manual DDL management