A Linux binary that is also a SQLite database: the SELF prototype turns strip into a DELETE and patchelf into an UPDATE

A Linux binary that is also a SQLite database: the SELF prototype turns strip into a DELETE and patchelf into an UPDATE

Farid Zakaria's SELF prototype is a Linux executable that is also a working SQLite database. The file you chmod +x and run keeps its load segments, symbols and library dependencies in tables, so the standard binary tools collapse into SQL: strip becomes a DELETE, patchelf an UPDATE, ldd a SELECT. 1

The idea has a two-stage paper trail, and the arithmetic between the stages is the story. On May 6, 2024, Zakaria and three coauthors posted "sqlelf: a SQL-centric Approach to ELF Analysis" to arXiv, cross-listed across software engineering, databases and operating systems; its abstract pitches a tool that lets users "probe ELF objects through the expressive power of SQL" by modeling existing ELF files as relational databases. Zakaria says he failed to get it published. Just over 27 months later, on August 23, 2026, the follow-up arrived, and in his words it is not "a database that describes an executable", but the actual file you chmod +x and run. The coverage so far is practitioner-shaped: a link post from Simon Willison. 2 1 3

How a SELF file runs: two tables and a magic string

SQLite reserves a 4-byte application_id field at byte offset 68 of every database file, and SELF stamps it with the ASCII bytes for "SELF" so an ordinary database never matches by accident. Linux's binfmt_misc subsystem is registered to fire on the SQLite magic at offset 0 plus the SELF stamp at 68, handing the file to a C interpreter that extracts the segments and runs them. Zakaria wires this up on NixOS; Willison offers the registration line for systems without it. 1 3 4

A SELF file needs only two tables to run: self_meta holds the ELF header as key-value pairs, and segments holds one row per program header with the bytes in a BLOB. A single symbols table with a b-tree index replaces the .gnu.hash bloom filter ELF maintains by hand, and the .dynstr strings table disappears because SQLite already interns strings. The remaining ELF sections become optional tooling tables; delete them and the program still runs. Zakaria's read is that ELF was a database all along: its section header table a table of tables.strtab string interning.gnu.hash a hand-rolled index. 1

The tool equivalences all follow from that schema, per Zakaria's post:

• ldd(1): SELECT soname FROM ldd, a view joining symbols and segments
• readelf -l: SELECT type,vaddr,memsz,r,w,x FROM segments WHERE type='load'
• strip(1): DELETE FROM sections; DELETE FROM notes; VACUUM
• patchelf: an UPDATE inside a transaction, instead of offset surgery on a packed file

1

In Zakaria's demo the strip query takes a 57,344-byte binary down to 49,152 bytes: 8,192 bytes reclaimed, exactly one-seventh of the file, all of it metadata the running program never needed. That share is our arithmetic on his figures. So is the next observation: both endpoint sizes are exact multiples of 4,096 bytes, the same number the SELF schema carries as its default segment alignment, and SQLite guarantees that a database file is always a whole number of equal-size pages. The file is page-granular end to end; what remains open, in the thread, is whether the BLOBs inside it can be laid out page-aligned too. 1 4 5

The thread's sharpest objection is answered by the rejected paper

The Hacker News user catlifeonmars can accept that an object file is viewable as a relational database, but asks the pointed question: "Why not SQL query engine over the object file using a virtual table abstraction?" That is not a hypothetical architecture. It is what arXiv:2405.03883 shipped, what Zakaria describes as remarkably simple virtual tables sitting over the ELF, and what he writes he moved past because he knew something much bigger remained. The objection asks for the 2024 status quo; the prototype's actual bet is executability, since queryability already shipped in 2024 and, by Zakaria's account, failed to get published. What he says changed in between is one thing: recent improvements in LLMs. 5 2 1

The Hacker News objections, on the record

The thread is not a cheering section. The sharpest line names the loader: "The copied vs. mapped memory situation is the only deal breaker in this experiment," writes the user garganzol, on the premise that ELF segments can be mapped straight out of the file while a BLOB inside a database has to be copied. The user dolmen asks whether the format could be rewritten so segment BLOBs are page-aligned and mmap-able for loader shortcuts, the same constraint approached from the tooling side. Garganzol's same comment observes that the PE COFF format used by Windows and .NET assemblies are relational databases too, and the user dcrazy compresses the historical objection into one line: "Congratulations, you've rediscovered mainframes." 5

Zakaria says he never let the idea go and that recent improvements in LLMs made revisiting it compelling. 1 On our reading, the logic is structural: an agent that can already issue SQL needs no bespoke parser to interrogate a SELF binary, and a self-describing schema turns binary inspection from a tooling problem into a query. SELF files are still converted from ELF by an elf2self hook rather than emitted natively by the compiler or linker, which Zakaria frames as the simple way to explore the idea. 1

The bet, on our reading: the prototype will not replace ELF next quarter, and the thread says why. What it demonstrates is smaller and more useful, that a seventh of a binary can be pure bookkeeping, the bookkeeping was relational all along, and the tools maintaining it each reimplement database operations by hand. When the next consumer of a binary is an agent that already speaks SQL, admitting a format is a database stops being a thesis joke and becomes an interface decision.