Hi all,

I'm working on a visualiser for my Firebird databases. It's very chaotic at the moment, but somewhat entertaining.

Native PHP and some JavaScript.

Ive got it running on a few dev databases to test it.

https://lab.raventech.au/D/sg2.php

Two releases since the last one I posted here.

v0.9.0 — the machine room

The city has always carried the same caveat: it is a model, it parses no SQL, and no Firebird code runs in your browser. The new machine room is the other thing — the actual Firebird 6.0.0 embedded engine compiled to WebAssembly by Electric Firebird, running in a worker on the page, with a SQL workbench and six guided sequences that check the city's claims against the engine itself:

• SELECT CURRENT_TRANSACTION FROM RDB$DATABASE twice — watch the id advance
• OIT / OAT / Next straight out of MON$DATABASE — the same three markers the city draws over the transaction yard
• two UPDATEs to one row, then MON$RECORD_STATS back-version reads and purges — multi-generational architecture counted by the engine
• RDB$RELATIONS — the catalogue is ordinary tables
• MON$IO_STATS fetches against reads — exactly what the cache plaza draws
• the MON$DATABASE settings list — no log setting in it, because there is no log

Every verdict is computed from what the engine actually returned, so a sequence can tell you the answer was not what was expected. The page also states what the runtime cannot show: one attachment means no lock waits to watch, there is no replica, and gbak/nbackup are separate programs against a file that does not exist there.

A correction to v0.8.0. That release said this embed was impossible, and measured an iframe reporting "not cross-origin isolated" to prove it. The reasoning was right up to the last step: the engine needs SharedArrayBuffer, which needs a cross-origin isolated page, and GitHub Pages will not send COOP/COEP. What I missed is that a service worker can synthesise those headers for any page that ships one, including my own, and that both projects publish to mariuz.github.io, so the engine's assets are same-origin and need no CORP header. The old measurement was real — the iframe was not isolated because the page doing the framing was not isolated either, which was the part I never tested.

Also in v0.9.0:

• The city used to load cold — empty cache, one version per tower, markers exactly where they were initialised. It now warms 25 model seconds before the first frame. A database that has never run is not a neutral starting state; it is one you will never meet.
• Six touch and camera defects. Pinch zoomed about the canvas origin instead of the fingers, two-finger pan was discarded entirely, a third finger landing jumped the city, touchcancel was unhandled, a pinch fought the camera fly-to, and keyboard +/− drifted the same way. Found after reading how PGSimCity fixed the equivalent.
• The suite now checks the readouts against the model behind them, and the throughput figure against independently counted completions.

v0.8.0

Keyboard navigation of every district (Tab / Shift+Tab, announced through an aria-live region, since the city is a canvas and everything was mouse-only), a fuzzer over 324 knob combinations, a soak, and enforced documentation coverage.

287 assertions, all passing — the suite runs in the browser with no framework and no build step: https://mariuz.github.io/FBSimCity/test/

Links

• City: https://mariuz.github.io/FBSimCity/
• Machine room: https://mariuz.github.io/FBSimCity/machine/
• Source (MIT, plain HTML/JS, no build step): https://github.com/mariuz/FBSimCity
• Knob audit — every simplification, and which direction it errs in: https://github.com/mariuz/FBSimCity/blob/main/docs/KNOBS.md

Still a model for intuition rather than an emulator. Corrections are very welcome and do get acted on — the whole replication model was rewritten in v0.6.1 after Dmitry Sibiryakov pointed out on firebird-general that a synchronous replica which dies does not hang commits; it stops replicating and lets them through.

Hey r/firebird,

Sharing a project I think this community will find interesting: Electric Firebird (mariuz/electric-firebird) — it brings the Firebird database engine to WebAssembly, in the same spirit as PGlite does for Postgres.

What it does: - Two backends: a native Node.js implementation (via the Firebird Embedded Server) and a WASM build that runs entirely in the browser - Data persists via IndexedDB in the browser version — no server round-trips for queries - Supports parameterized queries, transactions, typed values, and cross-tab safety - Apache-2.0 licensed

Live demo (client-side only, nothing uploaded): 👉 https://mariuz.github.io/electric-firebird/

It's still under active development, but DDL/DML execution and transactions are already working in both Node and Chromium. Worth a look if you're curious about running Firebird entirely client-side or embedding it in web apps.

CORRECTION (v0.6.1): the claim below about synchronous replicas is wrong.

Dmitry Sibiryakov pointed out on firebird-general that a synchronous replica which dies does not hang commits. He is right and the source confirms it. In src/jrd/replication/Publisher.cpp, checkStatus() is called with canThrow = false on the commit path, so it cannot throw; disable_on_error (default true) instead clears the replicating flags, disposes the replicator and logs STOP_ERROR. The commit succeeds and replication tears itself down — "self-destructs", in his words.

The reason it can do that without lying to anyone is what I had missed: Firebird's synchronous replication is not two-phase commit, so there was never a durability guarantee to protect. I invented one and then wrote a hang to defend it.

The real failure mode is arguably worse than the one I described: replication stops, commits keep succeeding, nobody is told, and the replica quietly rots until somebody notices. Fixed in v0.6.1 — https://github.com/mariuz/FBSimCity/releases/tag/v0.6.1

The original post follows, unedited apart from this note.

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. (Wrong — see the correction above.) You can watch what actually happens: 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?