Backup and restore

Your memory lives in one place — your database. Backing it up is a normal database problem, plus one Sigil-specific export for when you want the content in a portable form.

Export

sigil export --format=json --output=brain-2026-08-14.json
sigil export --format=markdown > brain.md
sigil export --namespace=engineering --format=json

Flag	Effect
--format=json	Structured export: facts, entities, documents (default)
--format=markdown	Human-readable, good for review or committing to a repo
--namespace=<ns>	One namespace instead of the default
--output=<path>	Write to a file instead of stdout

Export is a content backup, not a byte-for-byte one. It carries facts, entities, and documents. It does not carry embeddings, lifecycle state, Hebbian edges, or access counts — those are derived and can be rebuilt.

For a true backup, dump the database.

Database dump

External Postgres

pg_dump "postgres://user:pass@host/sigil" > sigil-2026-08-14.sql

# restore
psql "postgres://user:pass@newhost/sigil" < sigil-2026-08-14.sql

Embedded (PGlite)

The embedded database is a directory. Stop the daemon first so nothing is mid-write:

sigil daemon stop
tar czf sigil-db-2026-08-14.tar.gz -C ~/.sigil db
sigil daemon start

Restore by stopping the daemon, replacing ~/.sigil/db, and starting it again.

Back up ~/.sigil/config.json too if you want to restore configuration rather than re-run setup. It contains your API keys and database credentials — treat it as a secret. It’s chmod 600 for a reason.

Moving to a new machine

Shared database

Nothing to move. Install Sigil on the new machine and point it at the same database:

curl -fsSL https://raw.githubusercontent.com/Anmol-Srv/sigil/master/install.sh | sh
sigil init --url "postgres://user:pass@host/sigil?sslmode=require"

Migrations find the schema already current. Your whole brain is there.

Carrying the data

# old machine
pg_dump "$OLD_URL" > sigil.sql

# new machine
psql "$NEW_URL" < sigil.sql
sigil init --url "$NEW_URL"
sigil migrate            # apply anything newer than the dump
sigil doctor

Embedded → Postgres

The built-in PGlite database can’t be shared between machines. To graduate:

sigil export --format=json --output=brain.json    # 1. save the content

Then Settings → Change database (or sigil init --url "…") to point at your Postgres. Sigil creates the database if it’s missing, enables pgvector, and runs migrations against the new target.

Facts don’t migrate automatically — re-ingest them from your export, or simply re-remember the ones that matter. Embeddings have to be recomputed against the new store either way.

Decide this early

If there’s any chance you’ll want multi-device memory, pick a real Postgres at setup. Neon’s free tier takes a minute to provision and skips this migration entirely.

Changing embedding provider

Switching embedders is the one configuration change with a data consequence: existing vectors were produced by a different model, and mixing them degrades retrieval silently.

Sigil catches this. When you change providers, the dashboard reports exactly how many rows are affected and makes you choose — wipe and re-embed, or cancel. It never half-applies.

All providers are pinned to 1024 dimensions, so the schema never breaks. It’s the semantic space that differs.

Starting over

sigil reset              # confirm, then drop the database and wipe everything
sigil reset --yes        # skip the prompt (scripting)
sigil reset --keep-db    # wipe config and disconnect agents, keep the data

reset is destructive and does what it says. Export first.

To remove Sigil from your agents without touching data, use sigil uninstall instead — see Uninstalling.

A sensible routine

# weekly, if your brain matters to you
sigil export --format=json --output="$HOME/backups/sigil-$(date +%F).json"

If you’re on managed Postgres, your provider’s automated backups already cover the real thing. The export is for portability and for reading your own memory back in a form you can diff.