Queryable Executables
- ID
- 18214
- Status
- summarized
- Published
- 26 Aug 2026, 8:20 AM
- Fetched
- 28 Aug 2026, 2:57 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://fzakaria.com/2026/08/24/actually-queryable-executables
- Source URL
- https://hnrss.org/best
Summary
- Score
- 5.5
- Created
- 28 Aug 2026, 4:01 AM
- Tags
- Audience
- developersdatabase_learnersvibe_coders
What happened
Farid Zakaria demonstrates SELF, an executable format where the program itself is a SQLite database, using Linux's binfmt_misc to trigger a custom interpreter that maps database rows into memory segments. He builds self-httpd, a proof-of-concept single-file webserver that stores the program, website content, routes, and all visitor state (logs, button presses) transactionally inside the same SQLite file it runs from—no /var/, /tmp/, or separate filesystem needed. The live demo runs at https://selfdb.exe.xyz, and the approach is inspired by Justine Tunney's redbean (a single-file webserver using self-extracting ZIP archives).
Why it matters
This is a thought-provoking experiment, not something to adopt in production. The practical takeaway is architectural: if your executable and your state live in the same SQLite file, you eliminate an entire class of deployment plumbing—config files, log directories, separate databases, volume mounts. For builders shipping small single-binary tools or edge-deployed services, the idea of collapsing program + state + logs into one queryable file is worth considering for specific use cases, though the reliance on binfmt_misc and the novelty of the format make this unsuitable for anything beyond experimentation today.
Discussion angle
What actually breaks when your program writes to the file it's executing from—concurrency, updates, backups, and what does this approach make trivially easy that traditional deployment requires significant plumbing for?