A prototype called SELF (Structured Executable & Linkable Format) replaces the ELF binary format with an actual SQLite database file: the executable itself is a .sqlite file, queryable and modifiable via SQL. The author frames ELF as a hand-rolled database (string tables as interning, hash sections as indexes, section headers as a schema table) and shows how stripping symbols becomes a DELETE+VACUUM transaction, patching becomes an UPDATE, and ldd becomes a JOIN. Using binfmt_misc and a custom interpreter (self-exec), SQLite-backed binaries run natively on NixOS. Dynamic linking is implemented two ways: via glibc's rtld-audit interface backed by SQL queries, and via a from-scratch SQL-based dynamic linker (self-ld). Benchmarks show a single stripped binary lands within 1% of ELF size, while packing an entire userland (723 executables, 400 libraries) into one database yields 611.9 MiB versus 644.4 MiB of separate ELF files, due to natural deduplication. Runtime overhead includes a fixed ~5ms SQLite startup cost and lack of shared mmap'd text pages between processes. The project and tooling (elf2self, self scan, self closure) are open source on GitHub.
Table of contents
§ ELF is a database that refuses to admit it§ What falls away§ How does it work?§ Dynamic linking§ Cost & Benchmark§ The system is a closure§ How far does this go? One file, one userland§ Where it standsQuestions this post answers
Is there a way to make ELF binaries queryable with SQL instead of using readelf and nm?
Yes, a prototype format called SELF (Structured Executable & Linkable Format) stores an executable's program headers, symbol table, and dependency edges as tables in an actual SQLite database file, which can be chmod +x'd and run directly. Tools like ldd, nm, and readelf become simple SQL SELECT queries, strip(1) becomes a DELETE plus VACUUM transaction, and patchelf becomes an UPDATE. Developers exploring alternative binary formats can follow experiments like this SQLite-as-executable approach on daily.dev.
How much bigger is a SQLite-based executable format compared to a normal ELF binary?
A single stripped SELF binary lands within 1% of the equivalent ELF size, for example a stripped coreutils binary at 1,794,048 bytes versus the ELF's 1,768,632 bytes. However, packing an entire userland of 723 executables and 400 shared libraries into one SQLite database totals 611.9 MiB versus 644.4 MiB for the separate ELF files, because shared libraries and symbols are deduplicated naturally through the database schema. Anyone weighing binary size and format tradeoffs can track experimental format benchmarks like this through daily.dev.
What is the runtime performance overhead of executing a SQLite-backed binary format instead of ELF?
There is a fixed startup cost of roughly 5 milliseconds to open the SQLite database and start the interpreter, plus a memory copy proportional to the binary's image size. This copy is more expensive than a normal ELF mmap because SQLite's b-tree pages are not memory-mapped, so two processes running the same binary do not share text pages the way mmap'd ELF binaries do. Engineers evaluating novel executable formats can dig into performance tradeoffs like these on daily.dev.