Adding Firebird support to HammerDB / call for feedback

[fdcastel]

I've been working on a Firebird (firebirdsql.org) driver for HammerDB and the branch is now feature-complete enough that I'd like to share it with the community, get feedback, and check whether the project would be interested in upstreaming it.

Branch: github.com/fdcastel/HammerDB / feature/firebird-support

What's in the branch

Following the same structural pattern as the existing src/postgresql/, src/mssqls/, src/mysql/ etc. drivers:

• TPROC-C (TPC-C-like OLTP)
  • 9 TPC-C tables + 2 secondary indexes, schema build via batched INSERTs (Firebird has no COPY/BCP).
  • All 5 client-side driver procedures (NewOrder/Payment/Delivery/OrderStatus/StockLevel) implemented with a 3-attempt MVCC update-conflict retry helper that catches Firebird's update conflict / lock conflict / SQLSTATE 40001 / isc_update_conflict markers.
  • All 5 PSQL stored procedures (PAYMENT_SP, OSTAT_SP, SLEV_SP, DELIVERY_SP, NEWORD_SP), called via SELECT FROM proc(...) so the Tcl side stays on the tdbc::odbc happy path.
• TPROC-H (TPC-H-like OLAP)
  • 8 TPC-H tables, scale-parameterised bulk loader.
  • All 22 queries adapted to Firebird's SQL dialect (SUBSTRING instead of SUBSTR, parenthesised IN (... LIST ...), Firebird-friendly date arithmetic, etc.).
  • Power test (RF1 → 22 queries → RF2 with geometric mean).
  • Multi-VU throughput test (server-mode inet://localhost:3050, since Firebird Embedded is single-process and can't be shared across threads).
• Driver wiring: tdbc::odbc against the upstream Firebird ODBC driver, mirroring the way src/mssqls/ already uses tdbc::odbc. No new TDBC backend, no new C extension. Connection-string templates are built by a single fb_build_connstr helper.
• Configuration: <firebird> block added to config/database.xml, and a config/firebird.xml mirroring config/postgresql.xml.
• CLI scripts: scripts/tcl/firebird/{tprocc,tproch}/ and the Python parallel under scripts/python/firebird/.
• CI: a GitHub Actions workflow (.github/workflows/firebird.yml) that runs on every push:
  • Windows (Firebird 5 Embedded via PSFirebird, ODBC driver via choco install firebird-odbc): full smoke + schema build + 200-txn TPC-C run + 5 PSQL stored procs install/exec + TPC-H load + 22-query power test + multi-VU throughput. Twelve verification steps, each writing a JSON result file bundled as a workflow artifact.
  • Linux (Docker image overlay on tpcorg/hammerdb:v5.0-base): builds the image and verifies that libfbclient, libOdbcFb.so and tdbc::odbc all load correctly.
• Docker: Docker/firebird/Dockerfile, same overlay pattern as Docker/{mysql,postgres,maria,mssqls}/.

What's deferred / known limitations

• GUI options dialog. The variable-binding helpers (setlocalfbtpccvars, setlocalfbtpchvars) are wired up so the modules read settings from configfirebird, but the Tk-based connection / TPROC-C / TPROC-H tabs (mirroring src/postgresql/pgopt.tcl) aren't built yet.
• tcount_fb transaction counter. Currently a stub. A real implementation would poll MON$STATEMENTS from a background thread to feed the GUI's TPM/NOPM display.
• hammerdbcli end-to-end inside the upstream binary release. Looks permanently blocked unless the Windows .exe is rebuilt with the new files via Bawt — the binary uses Tcl zipfs to bundle src/, modules/, etc., so on-disk overlays are ignored. The standalone tdbc::odbc CI verifications cover the same code paths, but this is one obvious deliverable that depends on the upstream release process.
• Linux SQL coverage in CI. Both libfbclient and isql-fb work fine on Linux, but the upstream Firebird ODBC driver — verified on both v3-0-1-release and the recent v3.5.0-rc1 — returns a garbled diagnostic record on every failed SQLDriverConnect: empty SQLSTATE, non-deterministic native code, and a message truncated to a single [ character. That makes the driver unusable behind tdbc::odbc on Linux for anything beyond the happy path. I'm looking to fix this in the firebird-odbc-driver project. The Windows job covers the full SQL path end-to-end, so TPROC-C/TPROC-H workloads do work — just not on Linux via this driver until that's fixed upstream.

On upstreaming

I've read CONTRIBUTING.md and I want to be upfront about the two things it flags for new database support:

1. Popularity / ongoing maintenance commitment. Firebird is a smaller player than the six DBs HammerDB currently supports, but it has an active user base, especially in Latin America and parts of Europe, where it's commonly embedded in vertical applications. I'm a long-time Firebird user, I maintain the PSFirebird module used throughout this work, its docker images, and I'm committing to ongoing maintenance of the driver if it lands upstream.
2. Process. Happy to follow whatever process you'd like — open a Discussion first, file an enhancement Issue, or submit the PR directly. Just let me know which is best.

If the team is interested, I'd be glad to submit a PR. The branch should be reviewable as-is, but I'll happily rebase, split into logical commits, run additional testing, or adjust scope based on what the code maintenance team would want to see.

Thanks for reading! And thanks for HammerDB!

[sm-shaw]

Hi, many thanks for the new discussion topic and the work on Firebird support for HammerDB it looks very interesting.
We discussed at length at the TPC-OSS subcommittee meeting on 12th May 2026.
One of the key decision factors with upstreaming support for additional databases is the requirement for ongoing maintenance. In the past we have had support for 2 databases that was deprecated for different reasons, Redis because performance was poor (as Redis is single-threaded) and Trafodion SQL on Hadoop which was discontinued as a project (and performance was also poor). Going forward we need to ensure that all of the code included with HammerDB is understood, maintainable and performant.
For now the best approach would be for you to maintain the Firebird support as a separate fork in parallel, we can link to the downloads and documentation from the HammerDB website and help promote it as you maintain it. As the fork matures, becomes fully functional and given the level of adoption of the fork we can consider at a later point whether full inclusion and support and maintenance with HammerDB would be warranted or to continue standalone.
The next steps would be to ensure that the current gaps such as the GUI, transaction counter etc are filled and there is support for the Firebird ODBC driver and it works on Windows and Linux. This way people could start to use it for comparative tests.
Also one thing to consider is at the next release for open source databases we have the new CI/automated test pipelines e.g. the following for MySQL #876 that will take any version from git clone to test, so this will be required or certainly recommended functionality for the open source databases. Note that we are expecting the new version of HammerDB soon with this functionality included for MariaDB, MySQL and PostgreSQL.
Bawt is what we use for building and this would need extending as well to automatically compile with a single command.
For the garbled diagnostic a possible line of investigation could be something similar to this https://core.tcl-lang.org/tips/doc/main/tip/718.md
Overall the way forward is a staged approach to make sure support, testing and maintenance are in place before considering inclusion in the main HammerDB tree for the best overall user experience.

[fdcastel]

Thank you, @sm-shaw, for the feedback and valuable insights.

I completely understand and agree with the team’s position.

I’ll continue working on this in a separate fork and will do my best to achieve full parity with the requirements.

[sm-shaw]

Excellent. Please keep us updated and when you have something ready we can e.g. provide links to the download. https://www.hammerdb.com/download.html
Full integration is a decision that would be put to the vote by the TPC-OSS subcommittee if/and when the time is appropriate.