badger

I wanted a practical way to understand what is actually inside SQLite and bbolt/BoltDB-compatible database files. Most database tools show tables, rows, or query results, but hide the physical storage layout: pages, b-trees, cells, records, buckets, freelists, overflow pages, and raw byte ranges. Badger exists because learning and debugging embedded database internals from docs or hex dumps alone is slow and painful.

Open a real SQLite database file, select a table or index in the b-tree list, filter the page list to that object, and inspect the matching pages byte by byte. The useful moment is seeing the logical object, physical page, parsed metadata, and highlighted byte ranges together in one interface. For bbolt, try opening an etcd-style bbolt file and navigating buckets, leaf pages, inline buckets, and overflow-backed values.

Badger is storage-first rather than query-first. It is read-only, detects supported formats from file contents, and keeps the interface centred around physical pages, b-tree objects, parsed metadata, and byte ranges. The layout is built for moving between storage objects, pages, hex detail, and metadata without leaving the keyboard.

The next direction is deeper inspection and polish: improving SQLite and bbolt coverage, making byte-range drilldowns richer, adding better navigation for complex files.