Software developer Farid Zakaria described an experimental executable format on August 24, 2026, that uses a SQLite database as the file a Linux system can mark executable and run. The prototype, named SELF for Structured Executable & Linkable Format, explores whether database tables can replace the established ELF binary format rather than merely catalogue an ELF file.
Zakaria’s premise is that ELF already performs database-like work through tightly packed structures that multiple tools must separately parse and serialize. SELF instead gives executable information an explicit schema. At minimum, a file needs two tables: `self_meta`, which represents ELF-header information as key-value pairs, and `segments`, which stores the load image with one binary object for each program header. A separate symbols table and database index replace several traditional symbol-related sections and lookup structures.
The approach could make inspection and modification more declarative. In the prototype, metadata used only by tools can live in tables for sections, notes and dynamic entries without being required to run the program. Removing such information becomes a database operation and transaction, while changes comparable to those made by `patchelf` can be expressed as updates. Information for dependency inspection can be exposed through joins and views rather than bespoke binary parsing.
SELF files are distinguished from ordinary SQLite databases through SQLite’s four-byte `application_id` field at byte offset 68. On NixOS, Linux’s `binfmt_misc` mechanism can match the SQLite header and that identifier, then pass the file to a registered interpreter. The project’s `elf2self` tool currently converts an existing ELF executable by extracting its headers and symbol table and writing them into the new database. It does not yet depend on compilers or linkers producing SELF directly.
Execution is handled by `self-exec`, a small C program linked against SQLite. It reads the relevant tables, maps loadable segments into memory, applies relocations and transfers control to the program’s entry point. The interpreter must remain an ELF binary itself; registering a SELF interpreter in the same format would create a recursive loading loop.
The prototype also experiments with dynamic linking. One route retains the standard `ld.so` loader and uses glibc’s runtime-linker audit interface to direct shared-object searches through SQL. That allows the existing loader to continue handling features such as lazy binding, thread-local storage, symbol versions and indirect functions. Another route replaces more of the dynamic linker and performs lookup and binding through database queries.
SELF is an exploration, not a proposed drop-in standard. Its source describes conversion tooling and a working interpreter, but does not establish production compatibility, performance or security across the Linux software ecosystem. Its immediate contribution is a concrete test of whether executable tooling could become simpler when binary structure is represented through a stable, queryable schema.
