Recovering from TRUNCATE in SQLite

Whether you typed it yourself or your AI agent did, here's exactly what to do after a TRUNCATE hit your SQLite — best options first, honest about the rest.

First, in the next 60 seconds

  • 1. Stop all writes. Quit the app, pause the agent, and don't run another query — every write reduces what you can recover.
  • 2. Don't restart, vacuum, or checkpoint the database. Those steps can permanently overwrite recoverable data.
  • 3. Make a copy of the current state now (a dump, a snapshot, or the raw file) before you attempt anything.

What just happened

TRUNCATE empties a table fast by deallocating its pages rather than deleting rows one by one. It usually auto-commits and is not logged per-row, which makes it harder to recover than a DELETE — log-based recovery is your main hope.

Your recovery options in SQLite, best first

  • 1

    Stop and copy the database file now

    SQLite is a single file. Before anything else, copy your.db, your.db-wal and your.db-shm somewhere safe. Every further write lowers your chances.

  • 2

    Recover from the WAL file

    If the database is in WAL mode and has not been checkpointed, recently written data may still live in the -wal file. Copy it before any process checkpoints or closes the database cleanly.

  • 3

    Restore a file backup or VCS copy

    A SQLite database is often committed or backed up as a file. Restore the last good copy from your backup, Time Machine, or even git, and reapply recent changes.

  • 4

    Filesystem undelete (if the file was deleted)

    If the whole .db file was removed, stop writing to that disk and run a file-recovery tool (e.g. photorec) — deleted files are often still on disk until overwritten.

If you have no backup

If the file was overwritten in place, fully checkpointed, and you kept no copy, SQLite data is gone — there is no server-side log to replay. The only durable protection is a tool that copies the file on a timer.

Make sure this never happens again

The honest truth: your coding agent will eventually run TRUNCATE again. The fix isn't to trust it more — it's to keep an automatic, recent snapshot so a bad query is a 30-second rollback instead of a lost weekend.

OopsDB takes an encrypted snapshot of your SQLite every few minutes and restores it with one command. It's free, open-source, and runs entirely on your machine — set it up in two minutes and the next TRUNCATE won't cost you anything.

See how it works

Free & open-source for local backups · optional €8/mo cloud vault keeps a copy off your machine · cancel anytime.

Related recovery guides

Recover from DROP TABLE in SQLite Recover from DELETE without WHERE in SQLite Recover from DROP DATABASE in SQLite TRUNCATE in Postgres TRUNCATE in Supabase TRUNCATE in MySQL TRUNCATE in Neon Cursor deleted my database
📋 The 8-step disaster checklist — print it before you need it
The exact first-10-minutes playbook from this guide, on one page. Get the link by email: