Your entire database fits in one file.
Add your tables, set rows and row sizes, and see how big your whole database really is. Spoiler: smaller than your node_modules folder.
Your tables
Presets are typical payload sizes — edit bytes per row if you know your real row size. Editing it switches that row to Custom.
The breakdown
users — 10,000 rows × 400 B3.81 MB
SQLite page overhead (~15%)585.9 KB
Indexes (~25%, rule of thumb)976.6 KB
5.34 MB
This file is your entire database. Copy it and you own everything.
Honest notes on the math
- 15% page overhead is a rule of thumb, not a measurement. SQLite stores data in fixed-size pages; rows that don’t divide evenly leave slack. Real overhead lands somewhere between 5% and 25% depending on row size.
- Indexes cost real space. Every index is a second copy of the indexed columns plus pointers. The 25% line assumes a few indexes per table — a heavily indexed table can double it, a table with none pays zero.
- The WAL file adds temporary size. Write-ahead logging keeps a separate journal during heavy writes. It checkpoints and shrinks, but don’t measure your file mid-import and panic.
- Deleted rows leave holes until VACUUM. SQLite marks deleted space for reuse rather than shrinking the file. Your file may read larger than your live data — that’s normal.
- Embeddings are the exception that proves the rule. A million 768-dim vectors is ~3 GB — genuinely large. It’s also a single file you can rsync, back up, and carry between providers. Try that with a managed vector service.