FBSimCity v0.6.0: the replication district — journal segments, commit order, and a synchronous replica that dies

FBSimCity, the explorable isometric city of Firebird internals, is at v0.6.0. This release adds a replication district.

Replication without a log

Firebird has no write-ahead log to ship, so its replication is logical — and it has to be. As each transaction commits, the changes themselves are written into a replication journal segment. When a segment fills it is sealed and queued for the replicator, and a new one opens behind it. Crucially, the segments preserve commit order, so the replica replays history exactly as the primary lived it.

That gets three buildings:

  • Journal Yard — where commits are journalled. If the segments cannot be shipped, they stack up here visibly.
  • Replicator — asynchronous ships at its own pace and the replica trails, so 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 the lag build, or set it unreachable and watch the segments pile up: run the replica-lag scenario. Bring it back and it resumes from the oldest unshipped segment, in order.

A synchronous replica that dies hangs commits

This is the behaviour I was most careful to get right. A synchronous replica that becomes unreachable does not quietly fall back to asynchronous. Silently downgrading would mean claiming a durability guarantee the configuration no longer has, so the commits hang instead — which is the honest behaviour, and the reason synchronous replication is a decision rather than a default. You can watch it happen.

A fourth operator decision

The replica is gone and its journal segments are accumulating on the same volume the database writes to. Nobody can say when it comes back.

  • 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.

Both answers cost something, and the verdict quotes numbers measured from the run rather than written in advance.

Also in this release

  • The test suite grew to 131 assertions, including commit-order preservation across segments and in-order catch-up after an outage. It caught the two new scenarios being undocumented before this shipped, and a version mismatch between data.js and the on-screen badge.
  • The top bar had been silently wrapping to two rows on narrower screens — a regression that crept in one button per release. It is a single row again.

City: mariuz.github.io/FBSimCity
Release notes: v0.6.0
Source: github.com/mariuz/FBSimCity (MIT, plain HTML and JavaScript, no build step)

It remains a model for intuition, not an emulator. What is real, what is merely scaled and what is a plausible stand-in is all written down in the knob audit. Corrections are very welcome, particularly on the replication mechanics, which I modeled from the documentation rather than from the engine source.

FBSimCity is an independent educational project, not affiliated with or endorsed by the Firebird Project. Firebird® is a registered trademark of the Firebird Foundation Incorporated.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

IBX for Lazarus 2.7.11 and 2.7.12 released

MWA Software has published two bug-fix releases of IBX for Lazarus, the Lazarus components for accessing Firebird databases.

2.7.11 (2 June) fixes field-to-column mapping when a SELECT uses aggregate or concatenation functions without an explicit alias. Firebird reports the same alias name for each function of a given type, and IBX’s disambiguation could previously associate fields with the wrong column.

2.7.12 (21 June, Build 1676) ensures that ApplyUpdates respects “OLD_” parameter values in custom update SQL — typically when updating a key field and the WHERE clause refers to the old key value (WHERE MYKEY = :OLD_MYKEY). Regression tests 4, 18 and 20 were extended to cover key updates.

Downloads are available from the GitHub release pages above or via the Lazarus Online Package Manager.

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading...

node-firebird v2.6.0 – v2.14.0: roadmap complete, issue tracker at zero

The pure-JavaScript node-firebird driver for Node.js shipped eight releases in under a week (v2.6.0 – v2.14.0), completing its entire roadmap and closing all 47 open issues — some dating back to 2015.

Highlights for Firebird users:

  • Firebird 6.0 Protocol 20 fully supported — the long-standing prepare hang was root-caused and fixed (v2.10.0)
  • The sporadic Srp/Srp256 authentication failure solved — ~1.2–1.7% of attaches failed with “Your user name and password are not defined”; retry workarounds can be retired (v2.8.1)
  • Real single-byte codepage support — WIN1250–WIN1258, ISO8859_2–9/13, KOI8R/KOI8U, DOS866, encode and decode (v2.13.0)
  • Firebird 4 batch API — bulk inserts via executeBatch (5–10× faster) and a new batchStream writable stream
  • Multi-host pooling (poolCluster) for primary/replica topologies on Firebird 4+ logical replication (v2.14.0)
  • Tagged-template queries, savepoints, affectedRows metadata, query cancellation with AbortSignal, first-class ESM

Read the full write-up on Mariuz’s blog.

Get it from npm, browse the code on GitHub, or see the detailed release notes.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Announcing cl-firebird v1.0.0: Pure Common Lisp Driver with Full node-firebird Parity & Multi-Version CI Matrix

We are excited to announce the release of cl-firebird v1.0.0 — a pure Common Lisp database driver for Firebird 3.0, 4.0, 5.0, and 6.0+. Featuring full 1:1 feature parity with node-firebird, this release brings 12-factor connection URIs, thread-safe connection pooling, named placeholder parameter binding, custom type parsers (type-cast), streaming cursors, database events (POST_EVENT), Service Manager support, Firebird 6.0 tablespaces/schemas, and an automated GitHub Actions testing matrix.

Key Highlights

  • Pure Common Lisp wire protocol (zero C / FFI dependencies): communicates directly over TCP sockets using Firebird’s remote protocol (negotiating up to Protocol 20); runs on SBCL, CCL, and other ANSI CL implementations without libfbclient.
  • 12-factor connection URIs & attach-or-create: firebird://user:pass@host:port/database?pageSize=8192 (IPv6 supported), traditional DSN syntax, and automatic database creation when missing.
  • Named placeholders & SQL injection protection: bind :name parameters from property lists, association lists, or hash-tables; escape / escape-string helpers cover strings, numbers, booleans, dates, octet vectors, and NULLs.
  • Built-in thread-safe connection pooling: auto-reaping of idle connections, safe queueing under heavy concurrency, and live metrics (pool-total-count, pool-idle-count, pool-active-count, pool-waiting-count).
  • Custom type parsers (type-cast) & statement caching: per-column custom decoders and transparent reuse of prepared server-side statements.
  • High-performance streaming & batches: sequentially streams large result sets row-by-row; execute-batch handles bulk inserts/updates.
  • Firebird 6.0 features & Protocol 20: tablespaces (create-tablespace, alter-tablespace, drop-tablespace), schemas, session search paths, and default schemas.
  • Database events & Service Manager: attach-event / detach-event for POST_EVENT signals, plus an administration API for backup/restore, user management, trace sessions, and diagnostics.
  • Comprehensive testing: a 66-check FiveAM test suite and a GitHub Actions CI matrix across Firebird 3.0, 4.0, 5.0, and 6.0-snapshot.

Links & Installation

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

FBSimCity v0.4.0: the backup yard — gbak pins the OIT, nbackup fills the delta

FBSimCity, the explorable isometric city of Firebird internals, is at v0.4.0. This release adds a whole backup yard, built around what gbak and nbackup actually do.

gbak: the backup that pins your OIT

gbak takes a logical backup online: it attaches like any other client and reads every table through a snapshot transaction. That snapshot is the interesting part, because it pins the OIT for the entire run. Garbage collection stalls, cooperative GC refuses to demolish anything, and the record version towers climb until the backup finishes.

This is why a nightly gbak against a busy database and a mysteriously bloating database are so often the same story. Now you can watch it happen instead of inferring it from gstat -h: run the nightly gbak scenario.

nbackup and the difference file

nbackup is the other half: a physical backup, incremental by level. Level 0 copies the whole file, level 1 only the pages changed since level 0, and so on. The chain is enforced in the model just as it is in reality: ask for a level 1 without a level 0 and it refuses, and Restore chain reports which levels a restore would have to apply, in order. Lose level 0 and the rest are waste paper.

Locking the database with nbackup -L freezes the main file so it can be copied safely while the server keeps running. Every page written from that moment lands in the difference file instead, a new orange pit beside the main excavation that fills up visibly and merges back on unlock. Forget to unlock and it grows for as long as you watch: see a locked database filling its delta.

Dirty pages stopped being free

This release also fixes a genuine falsehood in the simulation. Evicting a dirty buffer used to cost nothing, which quietly understated write pressure. It now writes the page out first, so a reader that needs a frame pays for somebody else’s write.

The interesting part is what that does not cause. Because commits flush their page under forced writes, which is Firebird’s default, dirty evictions stay rare on a healthy database at around 1% of evictions, and only start biting when the cache is too small for the working set, reaching roughly 5% at 16 buffers. The honest lesson is “your cache is undersized”, not “writes are bad”, and the new evictions (dirty N) readout shows exactly that.

A knob audit

Since the whole point is intuition rather than emulation, v0.4.0 documents itself. docs/KNOBS.md lists every control and readout, what it does to the model, and whether the mechanism is real, merely scaled, or a plausible modeled stand-in, followed by the deliberate simplifications. Sweep here is time-triggered rather than transaction-gap-triggered; lock contention is a probability rather than a wait-for graph; no SQL is parsed at all. It is all in the table, so nobody has to discover it by reading the source.

Also in this release

  • Subsystem controls now live on the subsystem: start a sweep from the GC depot, run backup levels or lock the database from the nbackup vault, forget to commit a transaction from the Transaction Hall.
  • The screenshot driver no longer leaks browser profiles, and form controls are 16px so iOS Safari stops zooming the page.

City: mariuz.github.io/FBSimCity
Release notes: v0.4.0
Source: github.com/mariuz/FBSimCity (MIT, plain HTML and JavaScript, no build step)

Corrections are very welcome, especially on the backup mechanics, which I modeled from the documentation rather than from the engine source.

FBSimCity is an independent educational project, not affiliated with or endorsed by the Firebird Project. Firebird® is a registered trademark of the Firebird Foundation Incorporated.

1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...

FBSimCity: an explorable city that shows how Firebird works

FBSimCity is an interactive visualization of Firebird internals: an explorable isometric city where every building is a 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.

The simulation is Firebird-flavored throughout: MGA record versions stack floors on towers with every UPDATE, the Next/OAT/OIT counters run live on the Transaction Hall — flip on a long-running transaction and watch the OIT pin garbage collection — a sweep truck tours the tables, and the page cache flashes hits and misses above the careful-writes excavation (no WAL here).

Version 0.3.0 adds a live version-chain inspector with real transaction ids, an accessible text walk of the whole pipeline at https://mariuz.github.io/FBSimCity/lifecycle.html plus a guided tour, a step-by-step query trace, scenario presets and shareable deep links like https://mariuz.github.io/FBSimCity/?scenario=stuckoit&warp=50&panel=mvcc which drops you into a stuck-OIT city with the chain inspector open.

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

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

It is a model for intuition, not an emulator — corrections from people who know the engine internals are very welcome.

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)
Loading...

IBPhoenix is Introducting Firebird 2.5 Maintenance Subscription

Although Firebird 2.5 has reached End of Life, many production systems still depend on it. Following the disclosure of several security vulnerabilities that also affect Firebird 2.5, IBPhoenix has introduced a Firebird 2.5 Maintenance Subscription for commercial users. Subscribers receive security-patched Firebird 2.5 builds based on the final official release, together with future security updates released during the subscription period.

For full details, including supported platforms, pricing, available maintenance options, and subscription information, see the Firebird 2.5 Maintenance Subscription product page.

1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...

Database Workbench 7 now available

Upscene Productions is proud to announce the next major version of the popular Firebird development tool:

Database Workbench 7.0

This new release prepares Database Workbench for the future. With a revamped user interface with many improvements and AI powered SQL and database development, we’re supplying database developers with the tools they need.
— Martijn Tonies, owner of Upscene

The new Welcome Window gives you access to your most recently used files and database connections, as well as shortcuts to major features in the application. Also new in this release: a dark mode, with specially tailored icons and a color scheme that’s easy on the eyes.

Read more
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...

New Ebook: Practical Firebird Performance Diagnostics

IBPhoenix is pleased to announce the release of a new free ebook:

Practical Firebird Performance Diagnostics: A Structured Approach

Unlike traditional performance tuning guides, this ebook focuses on the reasoning behind successful diagnostics. It introduces a structured framework that helps Firebird professionals move from observed symptoms to defensible explanations by classifying problems, selecting appropriate investigation strategies, interpreting evidence correctly, and using diagnostic tools with purpose.

The book covers the complete diagnostic process, from understanding why investigations fail to interpreting monitoring tables, trace sessions, profiler output, gstat reports, operating system metrics, and modern hardware behavior in the context of Firebird performance.

Whether you’re a database administrator, developer, consultant, or support engineer, this ebook provides a practical methodology for approaching complex performance problems with greater confidence and consistency.

The book is available for free from IBPhoenix store.

Happy reading!

1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5.00 out of 5)
Loading...

EmberWings 2026/2 Is Now Available

We’re pleased to announce that the June 2026 issue of EmberWings (2026/2) is now available.

This issue explores a theme familiar to every experienced Firebird developer: the space between what we observe and what is actually happening inside the database engine. As systems become faster and workloads more demanding, successful diagnostics increasingly depend not on collecting more information, but on interpreting the available information more carefully.

Our two feature articles examine this challenge from different perspectives. We look at the limits of Firebird’s monitoring infrastructure—what it reveals, what it cannot reveal, and why understanding those blind spots is essential for effective troubleshooting. We also explore how modern hardware is changing performance characteristics in unexpected ways, showing that faster processors and storage do not always translate into simpler performance tuning.

This issue also includes a comprehensive summary of the Firebird Usage and Developer Experience Survey, providing an interesting snapshot of today’s Firebird community and the technologies, platforms, and deployment models it relies on. You’ll also find an exclusive interview, insights into ongoing project development, a candid evaluation of a noteworthy tool, a curated selection of questions and answers from the Firebird community, and the latest project news.

As always, EmberWings is presented in a clean, print-friendly format designed for comfortable reading, whether you prefer reading on screen or on paper.

The latest issue is available only to all Firebird Associates and Firebird Partners. It will be available to the general public in September 2026.

Also, the March 2026 issue is now available to all readers.

1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...

1 2 3 494