Executable Is a SQLite Database

Original Article ↗ Hacker News Discussion ↗

Turning an executable into a SQLite database format prompts both admiration for its creativity and skepticism about its practicality. Commenters highlight how this approach could unify tooling, make binaries queryable with SQL, and even serve as a container for code, data, and plugins, but they stress serious trade-offs such as loss of mmap-based sharing, higher memory usage, and complexity in adapting SQLite’s storage layout. The conversation broadens into a recurring idea in systems design—replacing or backing file systems, executables, and even OS services with database-backed abstractions—while questioning where this “SQLite for everything” trend should stop.

Overall reactions

  • Many readers found the project fun, clever, and a “great hacker project,” especially the use of dynamic libraries and ELF internals.
  • Others appreciated the inventiveness but didn’t feel it solved a pressing problem for typical users; more clearly valuable to people who already manipulate ELF binaries.
  • Several compared it to existing ideas: Smalltalk/Lisp/Forth images, zip/JAR-style containers, redbean, DBOS, AS/400/PICK, and “everything is a database” OS notions.

Executable format & performance trade-offs

  • Major concern: text segments are copied out of SQLite B-trees instead of mmapped.
    • This prevents sharing text pages between processes and hurts memory and swap efficiency, especially on dynamic-link-heavy systems.
  • Some suggested:
    • Aligning and padding BLOBs so they become page-aligned, mmappable regions.
    • Increasing SQLite page size (e.g., 64 KB) to get large contiguous areas.
    • Writing a custom SQLite VFS to separate headers from data.
    • Using SELF→ELF conversion at load time so the running binary is a normal ELF.
  • Several noted that avoiding copies and enabling mmap is “the whole point” of executable formats, so this trade-off is nontrivial.

SQLite as container / filesystem / interface

  • Strong interest in SQLite as a generic, tooling-rich container format for executables, documents, images, and more; contrasted with ad-hoc binary formats and ZIP+XML (OOXML/ODF).
  • Some argued the filesystem is already a composable “database,” with directories acting like sub-databases; SQLite’s flat namespace is less suited for that.
  • Others liked the idea of a DB-backed filesystem that still presents a hierarchical tree to users but allows SQL-like queries over rich metadata.

Alternative designs and related tools

  • Multiple commenters suggested keeping ELF and exposing it via SQL virtual tables instead of changing the on-disk format.
  • Mentioned tools: osquery, nushell, Steampipe, SQLite virtual tables for mounting filesystems, and previous work using SQLite as an embedded app container.

Critiques, questions, and ambiguities

  • Some saw the project as using SQLite as a “favorite hammer” rather than a principled new object format.
  • One commenter challenged the article’s claim that SQLite “interns” strings; they report duplicated strings on disk and say interning must be done explicitly.
  • Others envisioned richer plugin and relinking mechanisms inside the SQLite executable, but these remain speculative.

Meta: titles and research culture

  • The HN title filter removing “Your” sparked calls for smarter or LLM-assisted de-clickbaiting, or rewriting “Your” → “My.”
  • The author’s note that academic feedback was harsh prompted discussion that low-level, “artful” systems work is undervalued relative to pure performance metrics.