How Twill DB is delivered

There is one engine and you reach it through one of two front doors. The backend it durably writes to is chosen by the connection string, not by a rebuild.

You want…UseBackend by URL
In-process, function-call latency (one app)Embedded via bun:ffi / the C ABIfile:// (local) or s3:// (disaggregated)
Multi-client access / existing Postgres toolsServer via the Postgres wire protocolfile:// or s3:///r2:///gs://

The one thing to remember

The storage backend is selected purely by the URL scheme passed at open time. file:// is pure-embedded with zero network; s3:// / r2:// / gs:// is storage-disaggregated and scale-to-zero. The engine, the C ABI, and your SQL are identical either way.

Browse the docs

Looking for design intent?

This section is the user documentation. If you want to understand how and why the engine is built the way it is — the storage seam, MVCC, the S3-CAS commit log, the lifecycle controller — read the Development Guidelines (the fourteen design specifications and implementation maps). To see what has shipped and what is next, see Releases & Roadmap.

Twill DB documentation · Licensed under AGPL-3.0. · Author