Skip to content
Tech News
← Back to articles

Queryable Executables

read original more articles
Why This Matters

This article highlights a groundbreaking approach where executables are stored as SQLite databases, enabling programs to manage their own state within a single file. This innovation simplifies deployment, enhances portability, and could revolutionize how applications are built and maintained in the tech industry.

Key Takeaways

I was pleasantly surprised and happy to see that my article ‘Your executable is a SQLite database’ resonated with people. It is a format I have been thinking about for a while, and the idea seems to have struck a chord with others.

A quick recap: SELF, a format where the program is a SQLite database. We can use binfmt_misc to trigger a custom interpreter that maps the rows in the segments table and jumps to the entry point, and a whole class of binary tooling collapses into SQL.

What keeps surprising me is how having the file format be a SQLite database keeps collapsing everything into SQL. One idea that was immediately evident to myself and others through comments: If the executable is a database, and a database is something you can write to, can the running program use it to also store its state? 🤔

Yes! 🤯 We can collapse not only a complete distribution but all the state for every application into a single file, alleviating the need for /var/ or /tmp/ or /home/ or any other filesystem. The program can store its own state in the same file it is running from, and it can do so transactionally.

self-httpd is a proof-of-concept webserver that does exactly that. It is a single file program executed from a database. The file contains the program, the website, the routes and all the visitor logs. All state is updated in the same SQLite file as the program itself.

# Our server is a single file, and it is a SQLite database $ file server server: SQLite 3.x database, application id 1397050438, ... $ ./server --journal wal 8080 self-httpd: serving 3 routes out of /srv/self/server self-httpd: listening on http://0.0.0.0:8080 with 4 workers $ curl -s localhost:8080 | head -1 <!doctype html> # nobody has pressed the button on that page yet $ sqlite3 server 'SELECT count(*) FROM presses' 0 $ curl -s -X POST -d press localhost:8080/api/press {"presses":1,"button":"press"} # the application data is inside the same database $ sqlite3 server 'SELECT id, at, button FROM presses' 1|2026-08-25 03:11:28|press # so was the GET that fetched the page in the first place $ sqlite3 server 'SELECT count(*) AS n, path FROM visits GROUP BY path' 1|/ 1|/api/press

This web-server is live at https://selfdb.exe.xyz.11If the site is not working for you, sorry. I deployed it on their smallest tier. I included a screenshot of the site just in case for posterity! It is one file, a SQLite database, and it is also the server. It is the website, it is the program, and it is the visitor log and state.

§Everything is my demon muse

I have a lot of admiration for the work of Justine Tunney, whose prior art redbean: a webserver in a single file, built as an Actually Portable Executable with a self-extracting ZIP archive, inspired the idea.

SELF is many ways is less brilliant. It relies on simpler tools to achieve something very similar but I’m amazed how much collapses into a single domain: SQL.

... continue reading