Announcing node-firebird v2.6.0: TypeScript 7, Query Cancellation, Firebird 6.0 Support, and More

We are thrilled to share the journey of our last 7 releases (from v2.3.3 to v2.6.0), which mark one of the most transformative periods in the history of the node-firebird driver.

With this series of releases, we’ve migrated the driver to native TypeScript 7, implemented native Promise & async/await APIs, added support for Firebird 5.0 and 6.0 features, and introduced robust query cancellation support.

Here is a comprehensive summary of what's new and why you should upgrade today!

---

🌟 Key Highlights & Milestones

1. The TypeScript 7 Era

In v2.4.0, we successfully converted the entire project to native TypeScript 7. This ensures type safety across the driver, provides a better developer experience, and guarantees native compilation without overhead.

2. Modern Promises & async/await API

Beginning in v2.5.0 (TypeScript Phase B), we introduced a modern Promise-based API alongside the classic callback structure. You can now write clean, modern asynchronous code using async/await naturally.

3. Query Cancellation via AbortSignal

With the release of v2.6.0, we’ve added full query cancellation support. By using standard JavaScript AbortSignal, you can cancel long-running queries via op_cancel protocol interactions.

4. Firebird 6.0 & 5.0 Feature Parity

node-firebird now fully supports modern database engines:

• Firebird 6.0 Support: SQL Schemas, Tablespaces, Native JSON, Named Arguments mapping, ROW types, and Protocol Version List Limit (maxNegotiatedProtocols).
• Firebird 5.0 Support: Scrollable Cursors, RETURNING Multi-Rows, SKIP LOCKED operations, Parallel Workers, and Inline BLOBs.

---

📅 Release-by-Release Breakdown

🚀 v2.6.0 — Query Cancellation

• Query Cancellation: Full implementation of op_cancel allowing you to pass an AbortSignal to cancel queries mid-flight.
• Release Page: v2.6.0 Release Notes

🚀 v2.5.0 — TypeScript Phase B & Safety

• Promises/async-await: Expanded TypeScript Phase B compiler improvements to support async/await structures.
• Security & Logging: SRP handshake logging is now gated strictly behind FIREBIRD_DEBUG, ensuring database credentials and secrets are never leaked in logs.
• Roadmap Updates: Added a comprehensive driver-parity comparison against popular database drivers (like pg and mysql2).
• Release Page: v2.5.0 Release Notes

🚀 v2.4.2 — Documentation Refresher

• Developer Resources: Added a complete table of contents, community/resources index, and a comprehensive contributing guide to encourage community participation.
• Release Page: v2.4.2 Release Notes

🚀 v2.4.1 — Clean Up & Refinement

• Modern Tooling: Refreshed README and ROADMAP for the TypeScript 7 era and tidied up the repository root.
• Release Page: v2.4.1 Release Notes

🚀 v2.4.0 — The Big Upgrade: TypeScript 7 & Firebird 6.0

Our largest release in recent history, packing major feature upgrades:

• TypeScript 7 Migration: Moved the compiler and codebases to native TS7.
• Firebird 6.0 Features: Added SQL Schemas, Tablespaces, Native JSON, ROW type, named argument mappings, and protocol negotiating limits.
• Firebird 5.0 Features: Scrollable Cursors, inline BLOBs, SKIP LOCKED support, and RETURNING clause enhancements.
• Authentication & Wire Encryption: Dynamic srp256/384/512 authentication and modern chacha/chacha64 wire encryption support.
• Stability Fixes: Corrected in-flight event notification duplications, fixed preparation hangs on Firebird 6.0, and prevented callbacks from hanging when a connection is abruptly lost mid-flight.
• Release Page: v2.4.0 Release Notes

🚀 v2.3.4 — Dependency Maintenance

• Lockfile Updates: Routine maintenance and package lock updates to ensure clean and secure builds.
• Release Page: v2.3.4 Release Notes

🚀 v2.3.3 — Protocol Adjustments & Stability

• Connection & Encoding: Connection-level character set mapping fixes, TCP keep-alive settings, and a new connectTimeout parameter.
• BLOB Enhancements: Implemented blobReadChunkSize and serialized blob reading internally to prevent deadlocks under Firebird's concurrent handle limits.
• Platform Support: Added a proxy trap to bind socket methods for seamless compatibility with Deno.
• Release Page: v2.3.3 Release Notes

---

🛠️ Upgrading

Getting the latest improvements is as simple as upgrading via npm:

npm install node-firebird@latest

We want to thank all our contributors and the community for their feedback, bug reports, and pull requests that helped make this modern era of node-firebird possible!

Have questions or want to help contribute? Head over to the GitHub Repository and join the discussion.

Working on new Firebird VS code extension , still work in progress

Not bad for a few days of work , There are still lot's of bugs and UI inconsistencies 

ps: It's a fork of existing extension but using updated node drivers and updated roadmap (Firebird 6 support / Typescript 6.x)

pps: I need to recover my MFA Azure Developer account to publish it soon 

Going Native-Free: Introducing the Pure Node.js Wire Driver for Firebird

Published in Engineering • Pull Request #168 Summary

If you have ever built Node.js applications that communicate with a Firebird database, you are likely familiar with the standard setup routine. Traditionally, high-level drivers depended heavily on the native client library (fbclient).

While highly optimized, relying on a native dynamic link library (.dll, .so, or .dylib) frequently meant dealing with tedious cross-platform installation headaches, complex environment paths, and architecture mismatches.

That era is coming to a close. With the merging of Pull Request #168, the node-firebird-drivers ecosystem is taking a massive leap forward by introducing a completely native-free, pure TypeScript/JavaScript implementation: node-firebird-driver-wire.

The Problem: The Heavy Weight of Native Clients

Up until now, configuring Firebird in a modern Node.js environment usually required pointing your package to a local installation of the Firebird client. If you deployed your application inside a streamlined Docker container or onto a serverless environment (like AWS Lambda), getting those native client binaries to coordinate correctly could be a major chore.

The Solution: PR #168 and node-firebird-driver-wire

PR #168 fulfills a highly anticipated community request (tracked under Issue #166) to introduce a pure Node.js wire protocol driver.

Instead of wrapping around C++ bindings or hooking into a local fbclient library, this driver implements Firebird's native network protocol completely from scratch using standard Node.js TCP sockets (net.Socket).

What this means for developers:

• Zero Native Dependencies: You no longer need to ensure that fbclient is installed on your host system.
• Seamless Cross-Platform Portability: Written in pure JS/TS, the code runs identically on Windows, Linux, and macOS without local compilation.
• Streamlined Container Deployment: Building lightweight Docker containers (like Node-Alpine) is straightforward without OS-level database packages.

Architectural Overview

Under the hood, PR #168 establishes a modular separation within the monorepo:

1. node-firebird-driver: The shared interface layer containing universal definitions.
2. node-firebird-driver-native: The legacy client layer that directly talks to the native C++ API.
3. node-firebird-driver-wire (New!): The pure JS/TS layer that encodes and decodes the wire protocol over raw network sockets.

How to Use It

Switching to the wire driver mirrors the syntax of its native counterpart:

import { createWireClient } from 'node-firebird-driver-wire';

async function main() {
    const client = createWireClient();
    
    const attachment = await client.connect('localhost:3050/your-database.fdb', {
        username: 'SYSDBA',
        password: 'masterkey'
    });

    const transaction = await attachment.startTransaction();
    const resultSet = await attachment.execute(transaction, 'SELECT * FROM USERS');
    
    // ... process database logic ...

    await transaction.commit();
    await attachment.disconnect();
}

---

Wrapping Up

PR #168 marks a significant milestone for the Node.js and Firebird developer communities. By shedding the requirement for native underlying libraries, node-firebird-driver-wire positions Firebird as a modern, nimble, and serverless-friendly option for JavaScript developers.

Practical Firebird Performance Diagnostics: A Structured Approach

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!

Firebird Adds Unix Domain Socket Support

Firebird is gaining support for Unix Domain Sockets (UDS) through PR #9034, a feature aimed at improving local inter-process connectivity, especially in constrained environments like Android and iOS. The change introduces a new unix:// connection string format and a RemoteServiceUnixSocket configuration option, allowing Firebird clients and services to communicate over filesystem-based sockets instead of TCP.

This is a meaningful enhancement for mobile and sandboxed platforms, where filesystem permissions can be easier to manage than network ports. It also opens the door for scenarios where applications can launch a Firebird server process and connect to it locally even when embedded mode is not viable, which was the core motivation described in linked issue #9033.

From an implementation standpoint, the PR updates both client and server networking layers to recognize and handle AF_UNIX sockets, adds cleanup and auxiliary event-socket handling, and extends support to Windows environments that expose Unix socket APIs. It also updates configuration, build detection, and documentation so the new transport is visible and usable across supported platforms.

At a glance 

• PR: #9034 — Feature #9033 - Support for Unix Domain Sockets
• Author: asfernandes
• Status: Open, non-draft, mergeable
• Scope: 13 files changed, +544 / -27
• Commits: 2
• Linked feature request: #9033
• CI: Check runs completed on a broad platform matrix, including Linux, macOS, Windows, Docker, and Android builds

Why it matters

• Better fit for mobile and sandboxed environments
• Enables secure local connections based on filesystem permissions
• Reduces dependence on TCP for local-only communication
• Expands Firebird deployment flexibility for modern app runtimes

How Firebird’s New Parallel Sort Changes Everything

 

Breaking the Single-Thread Barrier: How Firebird’s New Parallel Sort Changes Everything

1. Introduction: The Multi-Core Paradox

There is a specific economic and technical frustration well-known to database architects: authorizing the purchase of high-end silicon with 64 or 128 cores, only to watch the OS scheduler show a single thread redlining while the rest of the hardware sits idle. Despite the massive processing power available, the internal logic of many database engines remains tethered to a sequential execution model. In this scenario, your return on investment for modern hardware is effectively throttled by legacy code, turning expensive multi-core chips into underutilized silicon.

Firebird SQL, with its architectural roots in the InterBase 6.0 legacy, has long been celebrated for its modularity and transactional robustness. However, it too faced the "serial bottleneck" where individual requests were confined to a single thread. Pull Request 8990 represents a paradigm shift for the engine. By moving from sequential processing to internal parallelism within the Journaling and Recovery Database (JRD) layer, Firebird is fundamentally evolving to meet the demands of modern hardware. This post explores the five most impactful technical breakthroughs from this architectural advancement.

2. Takeaway 1: Moving Beyond the "One Request, One Thread" Legacy

Firebird’s server models—Classic, SuperClassic, and SuperServer—were designed for an era where memory was the primary constraint and single-core performance was king. While SuperServer introduced multi-threading to manage concurrent connections, the execution of any single SQL statement remained strictly sequential. Even with dozens of cores available, a large sort operation was a monolithic task that could only utilize one.

PR 8990 is not a simple patch; it is a fundamental rethinking of the JRD layer. Specifically, it involves the transition of the JRD Task Manager from a simple serial queue to a robust central dispatcher. This new dispatcher model allows the engine to decompose complex operations into parallelizable segments that can be distributed across a global thread pool. By rethinking the core task-handling logic, Firebird can now treat a single query as a coordinated multi-threaded effort.

"As the database industry transitions from a focus on raw clock speed to the exploitation of massive core counts, the internal mechanisms of relational engines must evolve to avoid becoming performance bottlenecks."

3. Takeaway 2: The "Snapshot" Secret to Parallel ACID Compliance

Maintaining Multi-Version Concurrency Control (MVCC) while multiple threads sort data simultaneously is a significant technical hurdle. Every record version’s visibility must be checked against the Transaction Inventory Page (TIP), which tracks whether transactions are active, committed, or rolled back. In a standard sequential execution, this check is a linear process; in a parallel environment, it risks becoming a nightmare of disk contention and locking.

To solve this, PR 8990 utilizes a snapshot-based approach to the TIP. Before a parallel sort begins, the primary thread captures an immutable list of transaction states. This snapshot is shared with all worker threads. Because this view of the database state is "frozen" for the duration of the sort, worker threads can perform visibility checks independently. This is a brilliant architectural trade-off: by creating an immutable local copy of transaction states, the engine eliminates the need for workers to lock or even access the actual TIP pages on disk, significantly increasing concurrency and throughput.

4. Takeaway 3: A Mathematical Facelift for Big Data

The transition to parallel sorting fundamentally alters the mathematical complexity of query execution. The engine now employs a parallel external merge sort that utilizes a "cascading merge" strategy. This is specifically designed to address Amdahl’s Law by minimizing the "serial fraction"—the part of the code that cannot be parallelized. By allowing worker threads to merge groups of runs (e.g., four threads each merging 25 runs into intermediate blocks), the engine prevents the primary thread from becoming a bottleneck during the final merge phase.

Operation Phase	Sequential Complexity	Parallel Complexity (PR 8990)
Data Fetching	O(n)	O(n/p) (I/O dependent)
In-Memory Sort	O(n \log n)	O((n/p) \log (n/p))
Disk I/O (Runs)	O(n)	O(n) (Often I/O bound)
Merging Phase	O(n \log k)	O((n/p) \log k)

Key: n = number of records, p = number of parallel workers, k = number of runs being merged.

By partitioning the data stream and allowing worker threads to handle blocks and merges simultaneously, the engine achieves high efficiency even on systems with 32 or 64 cores.

5. Takeaway 4: The Hidden Performance Multiplier for Indexing

While the benefits to ORDER BY and GROUP BY are the most visible, the secondary impact on metadata maintenance is a game-changer. A CREATE INDEX statement is essentially a massive sort operation followed by B-tree construction. On tables with billions of rows, these operations traditionally took hours, creating massive maintenance windows.

PR 8990 applies the parallel sort framework to indexing, reducing these windows to a fraction of their former time. Furthermore, the architecture prioritizes a "Safety First" design. The SortManager is engineered to handle exceptions with surgical precision: if a worker thread fails due to a disk error or resource constraint, the SortManager catches the exception, terminates the remaining workers, and cleans up temporary files. This ensures that even under failure conditions, the database remains in a consistent state without orphaned temporary data.

6. Takeaway 5: Surgical Precision in Resource Management

Administrators gain granular control over this new power through updates to firebird.conf and databases.conf. This is facilitated by Firebird's support for scoped-value configuration, allowing different performance profiles for different databases on the same instance.

Key parameters include MaxParallelWorkers and ParallelWorkerStackSize. Tuning the stack size is particularly crucial; it allows architects to prevent memory exhaustion when high worker counts are required. To minimize overhead, the engine utilizes a "warm thread pool"—threads stay alive and wait for signals from the JRD Task Manager, avoiding the expensive lifecycle costs of creating and destroying threads for every task.

# databases.conf example: Scoped-value support
# High-parallelism for analytical workloads
AnalyticalDB = /databases/analytics.fdb { 
    MaxParallelWorkers = 16 
    ParallelWorkerStackSize = 512K
    TempCacheLimit = 2G 
}

# Restricted parallelism for high-concurrency OLTP
OLTP_DB = /databases/transactions.fdb { 
    MaxParallelWorkers = 2 
}

Importantly, these operations are fully observable. Administrators can monitor parallel utilization in real-time via the MON$STATEMENTS table using the new MON$PARALLEL_WORKERS column, providing the transparency needed to fine-tune production environments.

7. Conclusion: The Future is Parallel

Pull Request 8990 is more than an optimization; it is a foundational milestone. The task manager and worker thread framework established here serve as the infrastructure for future parallel advancements, such as parallel table scans, join algorithms, and background garbage collection.

As datasets grow toward terabyte scales, the criteria for selecting a database engine must change. In an era where 64-core processors are the standard entry point for servers, a database that cannot parallelize its internal tasks is no longer a tool; it’s a liability. With this shift, Firebird demonstrates its ability to maximize local resource utilization and secures its trajectory as a high-performance, open-source RDBMS ready for the most demanding modern workloads.

Help Us Test the New Firebird Docker Images

Major Update: Help Us Test the New Firebird Docker Images

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:

# 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