Bucardo - Multi-Master PostgreSQL Replication That Actually Works

You've probably landed here because PostgreSQL's built-in replication isn't cutting it for your multi-master needs. Smart choice looking at Bucardo.

Bucardo is a table-based replication system that does what PostgreSQL's built-in replication can't: actual multi-master setups that don't corrupt your data. Jon Jensen and Greg Sabino Mullane built this at Backcountry back in 2007 because PostgreSQL's streaming replication is basically useless for anything beyond simple master-slave.

Reality check: PostgreSQL's built-in stuff only does master-slave. You want real bidirectional sync where multiple servers can all accept writes? Bucardo is literally your only mature option. Everything else is either marketing bullshit or will lose your data when conflicts happen.

The Trigger Hell That Actually Works

Bucardo uses triggers for everything. Every INSERT, UPDATE, DELETE fires a trigger that captures the change. Good news: it catches every data change religiously. Bad news: your write performance takes a hit - usually 10-30% slower depending on your workload.

Fair warning: triggers add overhead to every write operation. I've seen teams deploy Bucardo and wonder why their API response times suddenly doubled. Plan for this or you'll be explaining to your boss why the app feels sluggish after "that database improvement."

What you get for the performance hit:

• Pick your tables: Replicate exactly what you need, not everything like PostgreSQL's logical replication
• Cross-version magic: Works from ancient PostgreSQL 8.2 to current versions
• Conflict resolution that doesn't suck: Customizable rules for handling conflicting changes, unlike pglogical
• Network hiccups are fine: Queues changes when networks go down, better than streaming replication

The whole thing is a Perl daemon that can run anywhere - doesn't need to be on your database servers. Which is good, because you'll probably restart it a few times while figuring out the config format and debugging connection issues.

Multi-Master Reality Check

Multi-master sounds cool until you deal with your first conflict storm. Two users updating the same record on different nodes at the same time? Bucardo has to pick a winner. The conflict resolution rules work, but you'll spend time debugging why that critical update got overwritten.

That said, it's still the only mature option for true bidirectional sync. You can replicate between any number of nodes - I've seen 5-way setups that actually work in production. Changes usually propagate within 1-2 seconds when your network isn't being terrible, as documented in performance benchmarks.

Pro tip: Start with master-slave first. Many teams use Bucardo for one-way replication because it's more reliable than PostgreSQL's logical replication and gives you table-level control. Get comfortable with it before jumping into multi-master chaos.

Where Bucardo Actually Saves Your Ass

Zero-downtime migrations are where Bucardo really shines. Smartcar and Get Safe used it to migrate PostgreSQL versions without taking their apps offline. This is the killer use case - you sync your old and new databases, switch traffic when ready, and nobody notices.

I've personally used it for:

• Geographic distribution: Keep databases in sync across data centers (works great until your cross-continent network hiccups) - AWS multi-region setups benefit from this
• Legacy system hell: Syncing ancient PostgreSQL 8.x with modern versions because some vendor refuses to upgrade their app
• Development sanity: Creating test databases that actually match production data instead of stale dumps from pg_dump

Load balancing writes across multiple servers sounds good in theory, but conflicts will make you question your life choices. Better to use it for migrations and read replicas unless you really know what you're doing.

Before we dive deeper into Bucardo's architecture and setup pain points, let's see how it stacks up against the competition.

Current Status and Maintenance

As of September 2025, Bucardo version 5.6.0 remains the latest stable release - and yes, that version was released back in February 2020. Development has been quiet, which either means it's rock-solid stable or the project is slowly dying. Based on production usage, I'd bet on the former. The project maintains active development through its GitHub repository with 780+ stars and continues to receive community contributions and professional support from End Point Dev.

The software is released under the BSD license, making it freely available for both commercial and non-commercial use without licensing restrictions.

Triggers: Your Database's New Overhead

Here's what really happens when you set up Bucardo: it installs triggers on everything. Every table you want to replicate gets trigger functions that fire on every write. These triggers dump change info into tracking tables in the Bucardo control database.

This trigger hell gives you some nice features:

• Pick what to replicate: Row-level and column-level filtering actually works
• Transform data on the fly: Custom trigger logic for data cleanup
• Audit everything: Complete change history with timestamps
• Rollback-proof: Captures changes even from rolled-back transactions

But here's the kicker: every write now hits your database twice. Benchmarks show 10-30% write performance hit, and that's optimistic. I've seen it worse on tables with complex indexes.

When Conflicts Happen (And They Will)

Two users update the same record on different nodes at exactly the same time? Congrats, you've got a conflict. Bucardo has to pick a winner, and somebody's update gets lost.

Built-in conflict strategies that actually work:

• bucardo_latest: Last write wins based on timestamps (pray your clocks are synced)
• bucardo_source: Source always wins (useful for master-slave setups)
• bucardo_random: Flip a coin (seriously, this exists for testing)

Want something smarter? You can write custom conflict resolution in PL/pgSQL. I've built functions that:

• Add up conflicting inventory counts instead of picking one
• Keep critical fields from one side, everything else from the other
• Log conflicts to a table for manual review (you'll need this)

Pro tip: conflicts happen way more than you think. Test with realistic concurrent write loads or you'll be surprised in production.

Network Goes Down? Bucardo Keeps Trucking

Network hiccups between data centers? Bucardo just queues everything up and waits. When connectivity comes back, it processes the backlog. This actually works great until you have a 3-day outage and come back to a 50GB queue that takes hours to process.

What actually works in production:

• Retries with backoff: Configurable retry intervals so it doesn't hammer your network
• Batched updates: Processes changes in chunks instead of one-by-one
• Resume from interruption: If sync gets killed halfway through, it picks up where it left off
• Detailed logging: You'll need this for debugging why sync stopped at 3am

Just remember: a large backlog means your replica is stale for hours. Plan accordingly or explain to users why yesterday's data is "eventually consistent."

Setup: Plan for 2 Days Minimum

What you actually need:

• Perl 5.8.3+ with DBI and DBD::Pg (good luck on older systems)
• DBIx::Safe module - this one always breaks during install
• PostgreSQL 8.2+ with PL/pgSQL and PL/Perl (yes, you need both)
• A dedicated database for Bucardo's control schema (don't mix this with your app data)

Real setup timeline:
First day you'll fight with Perl dependencies and DBIx::Safe (this module always breaks during install). Then you'll create the control database and spend hours figuring out why the config syntax is so weird. By evening you'll test basic replication and watch it fail for mysterious reasons. Second day is debugging trigger permissions and connection strings until it actually works.

The installation docs are comprehensive but dry as hell. Half the config examples online are for version 4.x and don't work. Start with the pgbench example if you want to see it actually working. Windows? You're running the daemon on Linux and connecting to Windows PostgreSQL - no exceptions. And yes, the error messages are about as helpful as "something went wrong."

Production Reality Check

Start simple: One Bucardo daemon for 2-5 databases works fine. Don't overthink it until you actually hit performance limits.

Multiple instances: Large deployments run separate Bucardo daemons for different regions or table groups. This gives you:

• Load distribution when one daemon can't keep up
• Geographic wins - West Coast daemon talks to West Coast databases
• Failure isolation - one daemon dies, others keep working

What you'll actually monitor:

• Queue depth: When this grows, your replica is falling behind - check queue monitoring
• Conflict rates: Too many conflicts means your business logic sucks - see conflict debugging
• Daemon restarts: Count how often you have to kick it back to life - use systemd monitoring
• Sync lag: How far behind are your replicas really? - track with Bucardo status commands

Follow the upgrade procedures or you'll break production. Trust me on this one.

Modern PostgreSQL Features

Bucardo is old but not dead. It handles:

• TRUNCATE replication on PostgreSQL 8.4+ (finally)
• Foreign keys with constraint checking you can configure
• Partitioned tables - configure each partition separately, it's tedious
• JSON/JSONB works fine with triggers

The mailing list is where real support happens. GitHub issues get closed with "use the mailing list" so just start there. The mailing list archive search is from 2003 and finds nothing useful, but the community actually responds to real problems. Also, expect the Perl daemon to randomly die with "segmentation fault" and no stack trace - it's part of the Bucardo experience.