Category: General news

Firebird related news

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

Leave a comment

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.

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

Leave a comment

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.

FBSimCity: an explorable city that shows how Firebird works

Leave a comment

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.

IBPhoenix is Introducting Firebird 2.5 Maintenance Subscription

Leave a comment

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.

New Ebook: Practical Firebird Performance Diagnostics

Leave a comment

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!

EmberWings 2026/2 Is Now Available

Leave a comment

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.

TurboBird further development

Leave a comment

Mustafa on Firebird-general group : I would like to introduce my continued development of TurboBird. The tool was originally developed by Abdel Azem Motaz, but was discontinued around 2015. I took over the code about a year ago and have been continuously developing, modernizing, and extending it since then.

TurboBird is a Lazarus (FreePascal) project and is currently cross-platform, supporting both Linux and Windows.

🔧 Technical Base / Refactoring

The biggest step was the complete removal of SQLDB:

  • Full migration to IBX
  • No SQLDB used anymore
  • More stable behavior with complex statements / metadata
  • Overall better Firebird compatibility

Additionally, the project now features dynamic loading of Firebird client libraries and parallel use of multiple Firebird versions (2.5 → 6.0) within a single instance. Thanks to IBX, script execution with and without terminators is now possible.

🚀 Performance & Scalability

The TreeView has been completely reworked with Lazy Loading (objects are loaded only when expanded), significantly reducing initial load times. Performance remains stable even with very large catalogs, having been tested with:

  • ~1,000,000 domains
  • ~10,000 packages
  • Several thousand tables

📊 Monitoring / Low-Level Access

The Activity Monitor provides a display of attachments, transactions, and statements, with the ability to directly terminate attachments or statements when necessary.

🔍 Navigation / UI

  • Tree filter: For working efficiently with large databases.
  • Reworked tab system: Movable and more compact.
  • QueryWindow: Code and result views can be maximized independently. The editor is intentionally decoupled from the theme system for more stable rendering.

🧰 Integrated Tools

  • Visual QueryBuilder: Drag & drop functionality to generate SQL.
  • Routine runner: For procedures, functions, UDF, and UDR.
  • DataEditor (formerly CSVEditor): Supports reading, editing, and exporting multiple formats; includes DBReader integration for data recovery.
  • Buildin-Tools menu: For direct access to all integrated utilities.

💾 Backup / Restore

Migration to IBX (Tony Whyman code) has enabled:

  • Server-side restore: Recommended and stable.
  • Client-side restore: Currently with some limitations.
  • Multi-file restore implementation.

📁 Data / Export

  • Export to 14 different formats (including Markdown and HTML).
  • Clipboard export with limits to protect against large datasets.
  • Support for complex data types, including arrays.

🧠 Firebird-specific Features

  • Proper support for case-sensitive identifiers.
  • Correct handling of quoted / unquoted identifiers.
  • Multi-version handling via IBX.
  • Automatic handling for older Firebird versions (e.g., DummyRole).

⚠️ Known Issues

  • Embedded connections: Please consider known limitations.
  • Client-side restore: May be incomplete (server-side recommended).

This is more than just maintenance—it is a large-scale technical refactoring and functional extension. I would be very interested in your feedback, especially regarding tests with different Firebird versions, edge cases, or general ideas.

View Source & Releases on GitHub

Best regards,
Mustafa

Help Us Test the new Firebird Docker Snapshot Images

Leave a comment

We have been working on a significant overhaul of the official firebird-docker images, and a pre-release version is now available for testing at:

👉 Pre-release Container Registry

We would love to get feedback from the community before these changes are merged upstream.

What’s New

Firebird 6 Snapshot Images

The new images include a 6-snapshot tag built daily from the master branch of FirebirdSQL/firebird. This is the first time a Firebird 6 development snapshot has been available as a Docker image.

# Pull the latest Firebird 6 development snapshot
docker pull ghcr.io/fdcastel/firebird:6-snapshot

# Pull the latest Firebird 5 patch snapshot
docker pull ghcr.io/fdcastel/firebird:5-snapshot

Snapshot images are rebuilt daily, so you always get the latest development build.

Expanded Version Coverage

The image matrix has been significantly expanded to cover more versions and distributions:

  • Firebird 3.x: 3.0.8 through 3.0.13 (amd64 only; bookworm, bullseye, jammy)
  • Firebird 4.x: 4.0.0 through 4.0.6 (amd64; bookworm, bullseye, jammy, noble)
  • Firebird 5.x: 5.0.0 through 5.0.3 (amd64 + arm64; bookworm, bullseye, jammy, noble)
  • Firebird 6 snapshot: Daily build from master (amd64 + arm64)
  • Firebird 5 snapshot: Daily build from v5.0-release (amd64 + arm64)

How to Test

Pull the images directly from our pre-release registry to see how they perform in your environment:

Bash

# Latest stable (Firebird 5.0.3 on bookworm)
docker pull ghcr.io/fdcastel/firebird:latest
# Firebird 6 development snapshot ← Most wanted testers here!
docker pull ghcr.io/fdcastel/firebird:6-snapshot
# A specific version + distro
docker pull ghcr.io/fdcastel/firebird:5.0.3-jammy
docker pull ghcr.io/fdcastel/firebird:4.0.6-bookworm

We are especially looking for feedback on:

  • Starting a container and connecting via isql or your preferred driver.
  • ARM64 performance if you have compatible hardware (M-series Macs, Ampere, etc.).
  • Firebird 6 snapshot behavior: Any connection issues, startup errors, or unexpected behavior changes.

⚠️ Important: Pre-Release Notice

These images have not yet been merged into the official repository and may contain bugs. The Firebird 6 snapshot, in particular, is built from unreleased, in-development code.

Warning: Do not use pre-release or snapshot images in production environments. Snapshot tags (6-snapshot, 5-snapshot) are rebuilt daily and do not carry stability guarantees.

Feedback

Your input is vital to making these images solid before the official merge. Please report any issues, successful test results, or suggestions at the upstream pull request:

🔗 GitHub Pull Request #36

Whether it’s a simple “works great on my ARM64 machine” or a detailed bug report, all feedback is welcome.

Thank you for helping us improve the Firebird ecosystem!

— F.D. Castel

1 2 3 … 207