SELF: An Executable That Is Also a SQLite Database
Farid Zakaria stamps the marker SELF at byte 68 of a SQLite file, and a binfmt_misc rule lets Linux run the database as a program.
Illustrative image: stacked glass plates etched with fine grid lines, lit from below by warm light.
Farid Zakaria's SELF format makes the executable itself a SQLite database, which Linux runs through a binfmt_misc rule and a small C interpreter named self-exec.
At a glance
- The application ID at byte 68 of the SQLite file holds the value SELF, or 5345 4c46 in hex.
- The interpreter is self-exec, a C program linked against libsqlite3 that must itself stay an ELF file.
- Stripped coreutils: 1,794,048 B as SELF against 1,768,632 B as ELF, a gap of under 1 percent.
- 723 executables plus 400 libraries: a 611.9 MiB database against 644.4 MiB of ELF files.
- Startup adds a fixed 5 ms; the author calls the SQL loader a proof of concept, not production-ready.
On Linux, an executable has meant an ELF file for decades. In a post dated August 23, 2026, Farid Zakaria describes an alternative he calls SELF: an ordinary SQLite database that you chmod +x and run. As he puts it, this is not a database describing an executable but the file you actually launch.
Four bytes at offset 68
The SQLite header reserves a four-byte field called application_id, sitting 68 bytes into the file. Zakaria writes the string SELF there, short for Structured Executable and Linkable Format. Running xxd against that offset shows the bytes 5345 4c46, which is how a SELF file is told apart from any other database.
The kernel side uses binfmt_misc. Zakaria registers a rule that matches the SQLite signature at the start of the file and the SELF marker at byte 68, pointing at an interpreter called self-exec. That interpreter is a small C program linked against libsqlite3, and it has to remain a plain ELF binary — otherwise the kernel would keep invoking the format to run the thing that runs the format.
The loader reads SQL, not sections
Everything the loader needs lives in tables. Only two are required: segments carries one row per program header with the bytes stored as a BLOB, and symbols collapses the ELF symbol tables into columns such as name, version, value, type and bind, indexed on name and version.
The rest — sections, notes, dynamic_entries — is metadata. Delete those tables and the program still runs. Zakaria's underlying argument is that ELF hand-rolls a lot of database machinery: string tables become SQLite's own string interning, the ELF hash sections become b-tree indexes, and manual offset arithmetic becomes foreign keys. Under that model, strip is a DELETE followed by VACUUM, and patchelf is an UPDATE.
What it costs
A single hello binary roughly doubles in size. The picture changes at scale, as Zakaria's measurements show.
| Measurement | SELF | ELF |
|---|---|---|
| coreutils, stripped | 1,794,048 B | 1,768,632 B |
| Userland: 723 executables, 400 libraries | 611.9 MiB | 644.4 MiB |
For coreutils the difference stays under 1 percent, and a whole userland fits into a database smaller than the equivalent tree of ELF files, because shared libraries are stored once rather than repeatedly.
Startup carries a fixed cost of about 5 ms for SQLite initialization, plus an amount that scales with image size. That second part exists because the bytes are copied out of b-tree pages instead of being mapped in with mmap the way an ELF image is.
Packing dependencies
A self closure command bundles a program and all of its transitive dependencies into one database. Resolved library paths become foreign keys in a needs table, which removes the ambiguity of matching a program to a soname at runtime. For dynamic linking Zakaria built two paths: one keeps ld.so and hooks library lookups through glibc's rtld-audit interface so searches turn into SQL queries, while self-ld replaces the dynamic linker outright and resolves relocations and symbols from the database.
Where it stands
Zakaria is explicit that the SQL loader is a proof of concept rather than production code. One concrete limitation: two processes running the same SELF binary cannot share text pages, since the bytes are copied from b-tree pages. Conversion is meant to round-trip losslessly through a tool named elf2self, and the prototype is published as fzakaria/selfdb on GitHub. Simon Willison highlighted the write-up on August 24, 2026.
FAQ
What is the SELF executable format?
SELF stands for Structured Executable and Linkable Format. It is a SQLite database carrying the application ID SELF at byte 68, storing a program's segments and symbols in tables rather than in ELF sections.
How does Linux know to execute a SQLite file?
Through binfmt_misc. A registered rule matches the SQLite signature and the SELF marker at byte 68, then hands the file to the self-exec interpreter, which reads program headers and symbols out of the database.
Does a SELF binary start more slowly than an ELF binary?
Yes. There is a fixed overhead of roughly 5 ms for SQLite startup, plus a cost that grows with image size because segment bytes are copied from b-tree pages instead of being memory-mapped.
