GDB File Documentation

Summary

A .gdb file is an InterBase Database, the single-file relational database created by Borland InterBase (and read by early Firebird, which forked from InterBase in 2000). It stores tables, indexes, stored procedures and data together in one file organised as fixed-size pages. You do not open it in a viewer: you attach it with a database engine such as InterBase or Firebird and query it with SQL. Its generic MIME type is application/octet-stream.

Technical details

Feature	Value
Full name	InterBase Database File
File extension	`.gdb` (later InterBase uses `.ib`; Firebird uses `.fdb`)
MIME type	`application/octet-stream`
Format type	Single-file relational database (binary, paged)
Developer	Borland (InterBase); now Embarcadero. Firebird by the Firebird Project
Introduced	InterBase from the mid-1980s; Firebird forked from InterBase 6.0 source in 2000
Byte order	Depends on the creating platform (implementation ID stored in the header)
Page size	1024, 2048, 4096, 8192 or 16384 bytes; fixed at creation
On-disk structure	ODS version stored on page 0 (ODS 10 = InterBase 6.x, ODS 11 = InterBase 7.x)
Concurrency model	Multi-generational (MVCC): record versions tagged by transaction ID
Query language	SQL (dialect 1 and 3)
Open standard	No (InterBase proprietary; Firebird is open-source, InitDeveloper Public License)
Related extensions	`.fdb`, `.ib`, `.gbk` (backup), `.fbk`
Magic / header	No fixed ASCII signature; page 0 is the header page carrying the ODS version and page size
Also uses this extension	Esri File Geodatabase (a folder named `*.gdb`); Garmin MapSource GPS database (starts with ASCII `MsRcd`)
Specification	Embarcadero InterBase ODS docs

Structure at a glance

An InterBase .gdb has no fixed ASCII magic signature. It is a sequence of fixed-size pages (page size chosen at creation: 1024–16384 bytes). Page 0 is the header page: it holds the page type and flags, a page-generation counter, the database creation date, the implementation ID (which encodes the creating OS and byte order), the ODS version (on-disk structure number), and a pointer to the first pointer page. A tool identifies the file by reading page 0 and checking the ODS number rather than by matching leading bytes.

What is a GDB file?

A .gdb file is an InterBase database: a complete relational database packed into a single operating-system file. InterBase began at Groton Database Systems in the mid-1980s and became a Borland product; in July 2000 Borland released the InterBase 6.0 source code, from which the independent Firebird project forked. Both engines read the same on-disk layout, which is why a legacy .gdb can be attached by either. Newer InterBase versions renamed the default extension to .ib (partly because Windows XP’s System Restore watched .gdb), and Firebird adopted .fdb, but the file structure below is shared.

Unlike a document format, a .gdb is not something a viewer renders. It is a live database that a server process opens, and everything inside — tables, indexes, triggers, stored procedures, BLOBs — is addressed through fixed-size pages. The sections that follow describe those pages: how the header page identifies the file, how the page inventory tracks free space, how records are stored and versioned, and why the database can grow without ever rewriting itself.

Two unrelated formats share the extension and are worth ruling out first. An Esri File Geodatabase is a directory named something.gdb that contains dozens of internal files; it is GIS data opened in ArcGIS or the free QGIS, not a single database file. A Garmin MapSource GPS database is a single file too, but it begins with the ASCII tag MsRcd and holds waypoints and tracks. If your .gdb is a folder, or starts with MsRcd, stop here: it is not an InterBase database.

The page model: fixed pages and the page number

An InterBase database file is divided into fixed-size pages. The page size is chosen when the database is created — 1024, 2048, 4096, 8192 or 16384 bytes — and cannot be changed afterwards without a backup and restore, because every internal reference is a page number multiplied by the page size. All I/O happens a whole page at a time, so the page size also sets the granularity of the buffer cache.

Every page carries a small header identifying its type. The engine defines a handful of page types, each with a distinct job:

Page 0   Header page      database metadata, ODS version, page size, creation date
PIP      Page inventory   bitmap of which pages are allocated / free
TIP      Transaction inv. commit state of each transaction (committed / rolled back / limbo)
Pointer  Pointer page     the array of data-page numbers that make up one table
Data     Data page        the actual record versions
Index    Index root       entry point to a table's B-tree indexes
B-tree   Index page       packed, prefix-compressed key values
Blob     Blob page        large-object segments stored out of line
Generator Generator page  arrays of sequence counters

Because a page always names its own type, and because tables are reached indirectly through pointer pages, the file can be walked structurally: read page 0, find the metadata, follow pointer pages to data pages. Nothing in the file is positional in the way a flat format is; a table’s pages can sit anywhere in the file and are chained together logically.

Page 0 is the header page, and it is the one part of the file you can read directly to learn what you are holding. It records the page size, the database creation timestamp, a page-generation counter, an implementation ID that encodes the operating system and byte order of the machine that created the file, and — most importantly for compatibility — the ODS version.

ODS stands for On-Disk Structure. It is an integer that stamps which layout revision the file uses, and the server refuses to attach a database whose major ODS it does not understand (the classic unsupported on-disk structure error). The mapping is direct: ODS 10 is InterBase 6.x (and Firebird 1.0), ODS 11 is InterBase 7.x, and later majors follow the engine versions. A minor ODS number records incremental changes made by a specific server build. Because the ODS lives on page 0, identifying a .gdb means reading its header page and checking that number, not matching a leading magic string — InterBase files deliberately have no fixed ASCII signature.

Page inventory pages and space allocation

Free space is tracked by Page Inventory Pages (PIPs), each a bitmap in which one bit represents one page: set means allocated, clear means free. When the engine needs a new page it consults the PIP, marks a bit, and only then writes a reference to that page elsewhere. This ordering is deliberate and is part of InterBase’s careful write strategy: a page is marked used before anything points at it, so a crash can leave an allocated-but-unreferenced page (harmless, reclaimed later) but never a referenced page that was never allocated (corruption). The cost is occasional orphan pages after an unclean shutdown, which a sweep or backup/restore cleans up.

Multi-generational records: how MVCC lives on the data page

InterBase pioneered multi-generational concurrency control (MVCC), and the mechanism is visible in how records sit on a data page. When a row is updated, the engine does not overwrite the old row: it writes a new record version tagged with the transaction ID that created it and links it to the prior version as a back-version chain. Each transaction reading the database has its own transaction ID and consults the Transaction Inventory Page (TIP) to decide which versions are committed and visible to it.

The practical consequences follow directly from this layout. Readers never block writers and writers never block readers, because a reader simply follows the version chain back to the newest version committed before its own transaction started. The trade-off is that obsolete back-versions accumulate as “garbage” until a sweep (or ordinary access) collects them, and a long-running transaction pins old versions in place. This is why an InterBase or Firebird database that is never swept slowly grows and slows: the extra versions are real bytes on real data pages.

Pointer pages, indexes and BLOB storage

A table is not a contiguous region. Each table has one or more pointer pages whose payload is an array of data-page numbers; to scan the table the engine walks that array. Indexes hang off an index root page that names each index’s starting B-tree page, and the B-tree pages themselves store key values with prefix compression (each key stores only the bytes that differ from the previous key), which keeps index pages dense. Large values — long text, images, the contents of a memo column — are stored as BLOBs on dedicated BLOB pages and referenced from the record by a BLOB ID, so a data page never has to hold a multi-megabyte field inline.

Attaching, backing up and moving the file

Because a .gdb is a server database, you interact with it through the engine, not by copying it while it is live. The portable, version-independent way to move or archive one is the logical backup: InterBase’s gbak (Firebird ships the same tool) reads every table through SQL and writes a transportable .gbk/.fbk file, then restores it into a fresh database, rebuilding indexes and often bumping the ODS to the target server’s version. A raw file copy of a database that is in use risks capturing a torn, half-written page, which is exactly the failure the careful-write scheme protects against internally but a naive copy defeats. To read the data with modern tools, attach the file in a Firebird or InterBase client and query it; connectors exist for practically every language, since the wire protocol and SQL are the durable interface, not the byte layout.

FAQ

Why does InterBase refuse a .gdb with an “unsupported on-disk structure” error?

The server read the ODS number on page 0 and found a major version it does not support. A file created by a newer engine cannot be attached by an older one. The fix is to restore the database with a server that understands its ODS, or to have the creating server back it up with gbak and restore it into the version you have.

Can Firebird open an old Borland InterBase .gdb?

Yes for the ODS versions they share (Firebird 1.0 reads ODS 10, the InterBase 6 structure it forked from). For much older or much newer InterBase files you first do a gbak backup/restore to bring the database to a compatible ODS. The two engines diverged after 2000, so newer InterBase-only features do not round-trip.

Why does my database file keep growing even after I delete rows?

Deletes and updates leave old record versions on the data pages under MVCC; the file does not shrink itself. A sweep reclaims obsolete versions into free space (reusable, but the file stays the same size), and only a backup-and-restore actually rewrites the database into a compact new file.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents