History[07][08]

In July 2000, Inprise released the source code for the relational DBMS InterBase 6.0. Shortly after, the Firebird project was forked from the InterBase 6.0 code tree on SourceForge, and developers began working on platform builds and new ports and tools. Firebird 1.0 was released in March 2002 for Windows, Linux, and Mac OS X, with support for other platforms soon following. In November 2002, The FirebirdSQL Foundation (now known as the Firebird Foundation) was incorporated to support and raise funds for the developers of the Firebird DBMS.

Compression[09]

Firebird uses prefix and suffix compression for index keys.

Concurrency Control[10][11][12][13]

Firebird uses a multi-generational architecture, also known as multi-version concurrency control (MVCC), which uses record versions instead of read/write locks and transaction logs to provide external concurrency and consistency. In MVCC, the preceding version of every modified record is kept as long as it is needed by at least one transaction. Each record version is signed by the transaction which created it, and each transaction knows what other transactions are currently active. Transactions cannot modify records whose most recent version is uncommitted, and transactions cannot read record versions created by active transactions. This ensures that active transactions can always see a consistent view of the database at any moment. Since readers typically do not block writers when accessing the same data, OLTP and OLAP operations can occur simultaneously in Firebird.

Limited explicit pessimistic locking is available through the WITH LOCK feature. However, Firebird warns users that explicit locking is rarely needed and intended for experts.

Firebird uses both its own lock manager and operating system locking for consistency control of the on-disk structure.

Data Model

Foreign Keys

Indexes[09][14]

Firebird uses B-trees for indexes. Each index has dedicated index pages in the database and contains record locators in the leaf nodes.

When using an index to access a table, Firebird retrieves the necessary index information in one pass and creates a sparse bitmap, in which the true bits correspond to the page address and record offsets of records in the query. Multiple indexes can be used on a table by performing Boolean AND and OR operations on the bitmaps created from the indexes.

Isolation Levels[15][16]

Firebird supports snapshot isolation, snapshot table stability isolation, and read committed isolation. Snapshot isolation is the default isolation level and allows the transaction to see only changes committed before it started. Snapshot table stability isolation is similar to snapshot isolation but more restrictive. Once this level has started, other transactions cannot modify any tables that have changes pending.

Read committed isolation allows the current transaction to see all data changes by transactions which have committed since the current transaction started. There are two kinds of conflict resolution used in read committed isolation: one that reads the last committed version of a row and thus is non-blocking, and one that makes the transaction unable to modify any row that has pending updates from another transaction.

Joins[17][18]

The query optimizer picks the join order with the longest path and lowest estimated cost in terms of I/O operations and processing, in which a join path is defined as a sequence of joins. The cost of the join method is considered in the computation of the join cost.

Firebird uses nested loop join, sort-merge join, and hash join. The join algorithm is chosen as follows. If the join is an outer join, the join conditions are indexed, or the join conditions are inequalities, the nested loop join is used. If the join is an inner join and the join conditions are both equalities and not indexed, the sort-merge or hash join is used.

Logging[19]

Firebird does not include transaction logging facilities, but logging software is available from third-party vendors.

Query Interface

Storage Architecture

Storage Model

System Architecture

Views[20]

Firebird supports three types of virtual views: naturally updatable views, which can be updated automatically without needing to write triggers; updatable views, which are updated through underlying triggers and can accept UPDATE, INSERT, and DELETE statements; and non-updatable views.