The replication district, deferred from v0.5.0 and now built.
Replication without a log
Firebird has no write-ahead log to ship, so its replication is logical: as each transaction commits, the changes themselves are journalled into segments, sealed, and replayed on the replica in commit order. That is a genuinely different animal from PostgreSQL's physical WAL streaming, and it gets its own quarter of the city.
- Journal Yard — committed changes are journalled into the open segment. When it fills, it is sealed and queued, and a new one opens behind it. If they cannot be shipped, the sealed segments stack up in the yard where you can watch them accumulate.
- Replicator — asynchronous ships at its own pace and the replica trails; commits never wait. Synchronous makes the commit itself wait for the replica, so the primary runs at the speed of the slowest replica.
- Replica Database — a second database, drawn as its own shallower excavation, replaying the journal in commit order with its applied history filling in as it catches up.
Set the replica slow and watch lag build. Set it unreachable and watch the segments pile up. Bring it back and it resumes from the oldest unshipped segment, in order.
A synchronous replica that dies hangs commits
It does not quietly fall back to asynchronous. Silently downgrading would mean claiming a durability guarantee the configuration no longer has, so the model refuses to do it and the commits hang — which is the honest behaviour, and the reason synchronous replication is a decision rather than a default.
PGSimCity had to correct exactly this in their v0.29.0 ("synchronous standby loss now properly hangs commits instead of silently downgrading durability"). It is modelled correctly here from the start, and the test suite asserts it so it stays that way.
A fourth operator decision
The replica is gone and the segments are stacking up. Replication is asynchronous so the primary has carried on happily, but every committed change is still being journalled onto the same volume the database writes to.
- Stop replication and discard the backlog — the disk stops filling immediately, but the replica is no longer a replica. Bringing it back is a fresh backup and restore, not a resume, and until then you have no second copy.
- Keep journalling and wait — nothing is lost if it returns soon. If it does not, you are betting free space at a steady rate, and if the volume fills the primary stops too: a much larger outage than the one you were protecting against.
Also in this release
- Two scenarios:
replicalag(replica falling behind) andsyncstall(synchronous replica dies). - 27 new assertions, bringing the suite to 129: lag arithmetic, commit-order preservation across segments, accumulation while unreachable and in-order catch-up on return, the synchronous stall, and backlog discard on switch-off.
- Topbar fixed. Eleven nav items had been silently wrapping to two rows below ~1150px, doubling the bar height — a regression that crept in one button per release since v0.2.0. Labels shortened (with tooltips kept), the decorative subtitle now drops earlier, and phone padding is tighter: the bar went from 150px to 99px at 375px, and from 100px to 48px at 961px.
The test suite caught the two new scenarios being undocumented in the README before this shipped, which is precisely the job it was added to do.
Still not ported
The Patroni/etcd consensus layer from PGSimCity's v0.25.0 has no Firebird counterpart — there is no such component to model, and inventing one would be fiction rather than simplification. Multiple replicas with independent lag, selective replication via RDB$PUBLICATIONS, journal archiving and apply errors that halt replication until a human intervenes are all real and all absent; they are listed in KNOBS.md among the deliberate simplifications.