People often ask what storage engine FoxByte uses. The answer is PostgreSQL’s. Rows, indexes and the write-ahead log are stored by PostgreSQL 18 itself, unmodified, on local disk.
What FoxByte built is a storage layer around Postgres: instant copy-on-write branches, space management, and durability to object storage.
The decision
- Transaction speed must never be compromised. It was the project’s first locked requirement.
- Engines that separate compute from storage put a network hop under every page read and every commit.
- Stock Postgres on local disk keeps native latency. Branching, backups and time travel run beside the commit path instead.
How the pieces fit
Each branch is a copy-on-write clone, a ZFS snapshot and clone on macOS and Linux or a btrfs subvolume snapshot on Windows, served by its own Postgres. A branch of any size is created in seconds and only stores what changes.
Main’s write-ahead log and base backups are copied to S3-compatible storage by wal-g, which is what makes point-in-time restore and branching from just before a schema change possible. The commit never waits for it.
What it means in practice
- Full PostgreSQL compatibility: drivers, ORMs, tools and extensions work unchanged.
- Nothing to maintain below Postgres; upgrades follow upstream.
- The honest limit: each node keeps compute and storage on one machine. Moving a branch between hosts would need networked storage, which is not built.