Executables stored as SQLite databases enable queryable state and code in single files

The SELF format reimagines executables as SQLite databases, where code, configuration, and runtime state coexist in a single file. This collapses traditional filesystem boundaries by embedding application data, such as logs, user sessions, or dynamic content, directly into the executable. For engineers, this simplifies deployment and state management, as a single file can be copied, backed up, or versioned atomically. However, it also introduces operational challenges: mutable executables complicate integrity checks, and accidental corruption could render the program unusable. The approach trades filesystem complexity for database complexity, requiring robust transaction handling to avoid data loss during crashes or concurrent access

The proof-of-concept `self-httpd` demonstrates the practicality of this model by serving a website, logging visits, and recording button presses, all within the same SQLite file. The server’s state is queryable via SQL, enabling real-time introspection without additional tooling. For example, counting visits or retrieving logs becomes a matter of running `SELECT` statements against the executable itself. This blurs the line between code and data, but it also creates a single point of failure: if the database becomes corrupted, both the program and its state are lost. Engineers would need to weigh the convenience of unified storage against the risks of coupling runtime state to the executable’s lifecycle

Implementation relies on Linux’s `binfmt_misc` to intercept execution and launch a custom interpreter, which maps database rows to executable segments. The interpreter passes the file path as `argv[0]`, allowing the program to open and query its own database. This design avoids the need for `/proc/self/exe`, which currently doesn’t support `binfmt_misc`-triggered executables. While elegant, the approach is Linux-specific and requires kernel-level support, limiting portability. Additionally, the interpreter must release its SQLite connection before handing off to the program, ensuring no resource leaks. This introduces a small but critical dependency on the interpreter’s correctness, as failures could prevent the program from starting

The format draws inspiration from `redbean`, a single-file webserver that uses a self-extracting ZIP archive. Unlike `redbean`, which embeds Lua for dynamic responses, SELF leverages SQL for both configuration and state management. For instance, adding a new route in `self-httpd` involves inserting a row into a `handlers` table, rather than writing Lua code. This shift simplifies tooling but requires engineers to think in terms of database schemas for program logic. While SQL is familiar to many, it may not be the most intuitive language for defining application behavior, particularly for complex workflows. The trade-off here is between the flexibility of a general-purpose language (Lua) and the declarative simplicity of SQL

The long-term viability of this approach hinges on its ability to handle edge cases, such as concurrent writes, file locking, and performance at scale. SQLite’s write-ahead logging (WAL) mode, as demonstrated in `self-httpd`, mitigates some of these issues, but high-throughput applications may still struggle with contention. Additionally, the format’s reliance on a single file could become a bottleneck for large applications, where database size impacts startup time and memory usage. Engineers evaluating this model should consider whether the benefits of unified storage outweigh the potential downsides of mutable executables and database-specific constraints