Export SQLite Files

Graft stores SQLite database history as snapshots, but it can materialize and export normal SQLite database files for standard tools.

Materialized Worktree Files

By default, Graft materializes committed SQLite snapshots at their tracked worktree paths after operations such as commit, checkout, switch, pull, and merge-continue.

project/
  data.sqlite
  .graft/

data.sqlite is a normal SQLite file that tools can inspect. The repository history still stores a SQLite snapshot object under .graft/.

Export A Snapshot

Export the current worktree database state:

graft export --output data.inspect.sqlite data.sqlite

Export a committed revision:

graft export --source HEAD --output data.head.sqlite data.sqlite
graft export --source HEAD~1 --output data.previous.sqlite data.sqlite

JSON output:

graft export --json --source HEAD --output data.head.sqlite data.sqlite

The exported file is a regular SQLite database. It is not connected to the Graft volume after export.

Use External SQLite Tools

You can inspect exported or materialized files with tools such as sqlite3, DB Browser for SQLite, Datasette, or app-specific debuggers.

If you edit a tracked materialized file, commit the transaction and stage the path:

sqlite3 data.sqlite "INSERT INTO notes(body) VALUES ('external edit');"
graft add data.sqlite
graft commit -m "import external edit"

graft add includes committed WAL frames without checkpointing the source and stores only 4 KiB Graft chunks that differ from the staged or committed base, independently of the physical database’s SQLite page size. Application code can therefore use its normal SQLite connection. Use vfs=graft only when the application deliberately chooses the optional live Volume mode.

Disable Materialization

Materialization is controlled by repository config:

[worktree]
materialize_sqlite = true

It is true by default. Set it to false only for integrations that intentionally want volume-only database paths and do not want ordinary SQLite files in the worktree.