We did not invent branching Postgres
The copy-on-write-clone-as-a-database idea is Database Lab’s, and other Postgres platforms branch in some form too. What is ours is what happens after the branch exists.
After the branch exists
Attribution by login
Every schema change recorded with the login that made it, person or agent, which a client cannot change, and the tool the client reported.
A record you can prove
A hash chain inside the database, signed anchors outside it, and a verifier anyone can run.
A gate before the damage
Destructive commands refused by policy, and deletes without a WHERE refused.
Local disk, by design
Separating compute from storage puts a network hop under every page read and every commit. FoxByte keeps stock Postgres on local disk instead, and does branching, backups and time travel beside the commit path. Today that is the design, with its trade-off: a branch lives on the machine that made it.
What FoxByte is not
- Single primary. Each node keeps compute and storage on one machine; a standby can run on a second machine, but there is no sharding and no networked storage yet.
- One standby. High availability is a primary and a hot standby with a witness, not a multi-region cluster.
- Not a vector database. It is PostgreSQL, with pgvector bundled for when you need embeddings.
- One shared instance. Accounts own their branches and share main; there are no per-project quotas yet.
Judge it on your own data.
Install FoxByte and import a copy of the database you already run.
$ curl -fsSL https://get.thefoxbyte.com/install.sh | sh