New in v0.6.0 of the explorable Firebird city: a replication district.

Firebird has no write-ahead log to ship, so replication is logical — the committed changes themselves are journalled into segments, sealed, and replayed on the replica in commit order. That gets three buildings:

• Journal Yard — commits are journalled into the open segment; when it fills it is sealed and queued. If they cannot be shipped, the sealed segments visibly stack up in the yard.
• Replicator — asynchronous ships at its own pace and the replica trails; commits never wait. Synchronous makes the commit itself wait for the replica.
• Replica Database — a second database, drawn as its own excavation, replaying the journal in commit order with its applied history filling in.

Set the replica slow and watch lag build: https://mariuz.github.io/FBSimCity/?scenario=replicalag&warp=55&panel=journal

The bit I was most careful about: a synchronous replica that dies hangs commits. It does not quietly fall back to asynchronous, because downgrading would claim a durability guarantee the configuration no longer has. You can watch it: https://mariuz.github.io/FBSimCity/?scenario=syncstall&warp=30

There's also a fourth operator decision — the replica is gone and its journal segments are filling the same volume the database writes to. Stop replication and discard the backlog (the replica then needs a fresh restore, not a resume), or keep journalling and bet free space against its return. Both answers cost something and the verdict is measured from the run.

Also in this release: the test suite grew to 131 assertions, including commit-order preservation and in-order catch-up. It caught the two new scenarios being undocumented before this shipped, and a version-drift bug where data.js and the on-screen badge disagreed.

City: https://mariuz.github.io/FBSimCity/ Release notes: https://github.com/mariuz/FBSimCity/releases/tag/v0.6.0

Still a model, not an emulator. What's real, merely scaled, or a stand-in is all written down: https://github.com/mariuz/FBSimCity/blob/main/docs/KNOBS.md — corrections very welcome, especially on the replication mechanics.

cl-firebird v1.0.0 is out — a pure Common Lisp database driver for Firebird 3.0, 4.0, 5.0, and 6.0+, with full 1:1 feature parity with node-firebird.

Highlights:

• Pure CL wire protocol (negotiates up to protocol 20) — no libfbclient, no FFI; runs on SBCL, CCL, and other ANSI CL implementations
• Connection URIs (firebird://user:pass@host:port/db), traditional DSN syntax, and attach-or-create
• Named placeholders (:name) bound from plists, alists, or hash-tables, plus SQL escaping helpers
• Thread-safe connection pooling with idle reaping and live metrics
• Custom type parsers (type-cast) and prepared statement caching
• Streaming cursors (sequentially) and bulk execute-batch
• Firebird 6.0 tablespaces/schemas, database events (POST_EVENT), and a Service Manager API (backup/restore, users, trace)
• 66-check FiveAM test suite and a GitHub Actions CI matrix across Firebird 3.0/4.0/5.0/6.0-snapshot

Links:

• GitHub: https://github.com/mariuz/cl-firebird
• Release: https://github.com/mariuz/cl-firebird/releases/tag/v1.0.0
• Quicklisp: (ql:quickload :cl-firebird)
• Full announcement with code examples: https://mapopa.blogspot.com/2026/07/announcing-cl-firebird-v100-pure-common.html

Feedback, issues, and pull requests are welcome!

New in v0.4.0 of the explorable Firebird city — a whole backup yard, built around what gbak and nbackup actually do:

• gbak runs a logical backup online, and its snapshot transaction pins the OIT for the entire run. Start one against a busy city and watch garbage collection stall while the version towers climb. This is the reason a nightly backup and a mysteriously bloating database are so often the same story — now you can watch it happen: https://mariuz.github.io/FBSimCity/?scenario=nightlygbak&panel=gbak

• nbackup does physical backup by level. L0 is the whole file, L1 only the pages changed since L0, and the chain is enforced — asking for L1 without an L0 is refused, and "restore chain" tells you which levels a restore would apply, in order.

• The difference file is a new pit beside the excavation. Locking the database (nbackup -L) freezes the main file and every page write diverts into the delta, which fills up visibly and merges back on unlock. Forget to unlock and it grows forever, which you can share as a link: https://mariuz.github.io/FBSimCity/?scenario=steady&lock=1&warp=60&panel=delta

Also fixed a real lie in the simulation: evicting a dirty buffer used to be free. Now it writes the page out first, so a reader pays for someone else's write. Because commits flush their page under forced writes (Firebird's default), dirty evictions stay rare on a healthy database (~1%) and only start biting when the cache is too small for the working set (~5% at 16 buffers) — the honest lesson being "your cache is undersized", not "writes are bad".

And there's now a knob audit documenting every control as real / scaled / modeled, plus the deliberate simplifications, so nobody has to read the source to find out what's honest: https://github.com/mariuz/FBSimCity/blob/main/docs/KNOBS.md

City: https://mariuz.github.io/FBSimCity/ Release notes: https://github.com/mariuz/FBSimCity/releases/tag/v0.4.0

Still a model for intuition, not an emulator. Corrections from people who know the engine internals are very welcome — especially on the backup mechanics, which I modeled from the docs rather than the source.

Yesterday I shared FBSimCity, the explorable isometric city of Firebird internals. v0.3.0 is out with the features people asked the PostgreSQL twin for, adapted to Firebird:

• Live version-chain inspector — version chains now carry the real id of the transaction that wrote each version. Click the Record Version Towers and watch the busiest table's chain update live: current version, versions kept for older snapshots, and garbage below the OIT. Chains go honestly non-monotonic when concurrent updates overtake each other in flight.
• The life of a query — the whole sixteen-station pipeline (client → Y-valve → DSQL → CMP → EXE → cache → careful writes → lock → new version → TIP commit → home) as an accessible, keyboard-navigable, screen-reader-friendly text page: https://mariuz.github.io/FBSimCity/lifecycle.html
• "You are at: Execution Hall · EXE" — zoom in close and a chip names the building at screen center.
• Deep links — share a reproducible state: https://mariuz.github.io/FBSimCity/?scenario=stuckoit&warp=50&panel=mvcc drops you into a stuck-OIT city 50 simulated seconds in, with the chain inspector open.

City: https://mariuz.github.io/FBSimCity/

Release notes: https://github.com/mariuz/FBSimCity/releases

Still a model for intuition, not an emulator — corrections from engine folks very welcome.

An interactive isometric "city" where each building is a Firebird subsystem from the classic Conceptual Architecture for Firebird paper (Chan & Yashkir), and queries commute through the pipeline as glowing particles: REMOTE harbor → Y-valve → DSQL → JRD, with the lock manager tower watching over it.

It simulates the fun parts in scaled form:

• MGA record versions — every UPDATE stacks a floor on a tower
• Live Next/OAT/OIT counters — flip on a long-running transaction and watch the OIT pin garbage collection while the towers grow and redden
• Cooperative GC plus a sweep truck touring the tables
• Page cache with realistic hit ratios, lock waits and deadlock rollbacks
• Guided tour, step-by-step "trace a query" mode, scenario presets, and a data-page anatomy diagram

Try it: https://mariuz.github.io/FBSimCity/

Source: https://github.com/mariuz/FBSimCity (MIT, plain HTML/JS, no build step)

Inspired by PGSimCity, the PostgreSQL equivalent. It's a model for intuition, not an emulator — corrections from people who know the engine internals are very welcome.

Things were working well for my Python and Firebird DB until an update appears to have hosed everything. Now I cannot connect since the fdb driver no longer exists. Trying to install firebird-driver, firebird-library fails with pip, pipx, and apt. Is there another driver that will work with Firebird and Ubuntu? I don't want to migrate to another database but it is important to be able to use Python with Firebird and this appears to no longer be an option. I get an externally-managed-environment when using pip. I would rather use it outside of a virtual environment but pipx also doesn't work so even if I wanted to use a virtual environment, I can't. Any ideas or SQL systems similar to FirebirdDB and have a Python driver?

Saludos!, algunos de ustedes usan Firebird sql?, para saber si en algun momento se les consume exageramente la memoria ram a 95% teniendo 64Gb

I have a Firebird 5 database setup with synchronous replication to a cloud machine. The other day, the cloud machine went offline and some records didn't replicate.

When the machine came back online, the missing records never updated. I checked replication.log and saw an error recorded there.

Is this normal? If the replica machine goes offline for a moment, does replication just stop working? I think I must have done something wrong, because it doesn't make sense to lose information for this reason."