実行可能ファイルはSQLiteデータベースです

2026年8月24日原文(fzakaria.com)

概要

Nix と ELFの代替としてのSQLite に対する著者の執着
sqlelf や SELF （Structured Executable & Linkable Format）などのプロトタイプ開発
ELFの本質的な課題 と SQLiteを実行可能フォーマットとして使う利点
SELFファイル構造 と ツール連携の容易さ
サイズ・起動速度の比較 や システムとしての応用可能性

NixとSELF：新たな実行可能フォーマットの探求

Nix は革新的なアイデア実現のためのツールとして活用
ELFの代替 として SQLite を実行可能フォーマットに利用する着想
PhD研究時から着想を温め、 sqlelf というSQLでELFを探索できるツールを開発
SELECT name FROM elf_symbols などSQLでELF内部解析が可能
SELF （Structured Executable & Linkable Format）というプロトタイプをGitHubで公開

ELFは「隠れたデータベース」

ELF は実は多くの データベース的構造 を自前実装している
- 例： .strtab/.dynstr ＝文字列インターン、 .hash/.gnu.hash ＝インデックス、 section header table ＝テーブルスキーマ
SQLite は自己記述型・拡張性・安定性に優れ、クエリによる柔軟な情報取得が可能
ELF は編集や拡張が困難だが、 SQLite ならスキーマ拡張や不要データ削除も容易

SELFファイルの構造と利点

実行に必要なのは self_meta （ELFヘッダーのkey-value）と segments （プログラムヘッダーごとのBLOB）の2テーブル
- 例： segments テーブルは各セグメントの属性やバイト列を格納
symbols テーブルでシンボル情報を一元管理し、 .gnu.hash などの複雑な構造を排除
- インデックスも SQLite のB-treeで高速化
不要なメタデータ（sections, notes, dynamic_entries）は削除可能
- 削除は DELETE と VACUUM でトランザクション的に実現

SELFファイルの実行とツール連携

SQLiteのapplication_id （68バイト目）に"SELF"を設定し、 binfmt_misc で新フォーマットとして登録
- self-exec というインタプリタでSELFファイルを実行
elf2self ツールでELFからSELFへの変換が可能
既存のツール操作（ldd, nm, readelf, strip等）はSQLクエリで代替可能
- 例： strip はDELETE & VACUUM、 patchelf はUPDATE
ビュー や JOIN で複雑な情報も容易に抽出

動的リンクの実装

glibcのrtld-audit を利用し、シンボル解決をSQLクエリで実現
self-ld という完全SQLベースの動的リンカもプロトタイプ化
共有ライブラリの探索やバインドもデータベース操作で完結

サイズ・起動速度の比較

SELFファイル はSQLiteのB-tree分だけELFより大きいが、不要テーブル削除でほぼ同等サイズに圧縮可
起動時は SQLiteオープンの固定コスト（約5ms） と BLOBコピー によるオーバーヘッド
- ELFのmmapによるページ共有は不可

システム全体を単一ファイル化

SELF は単一実行ファイルだけでなく、 依存ライブラリも内包したクローズドなシステム としても利用可能
- 依存解決や配布の簡易化に寄与

まとめ：SELF/SQLiteベース実行フォーマットの可能性

ELF の複雑性や拡張性の低さを克服する新しい実行フォーマットの提案
SQLite の持つ自己記述性・拡張性・トランザクション性を活かした実装
ツール連携の容易さ や システムの一体化 など、従来のELFにはない柔軟性
実用化にはさらなる最適化や標準化が課題だが、 新しいパラダイムへの一歩

Hackerたちの意見

これめっちゃ楽しかった！最近、あの人は絶好調だね。

これじゃ足りないと思う！実際のアプリストアが同じファイルになったらいいのに。そうすれば、生きたアプリケーションになって、使い方に応じてファイルが常に更新される。コピーして持ち運べば、データも一緒に持っていけるし。もっと深く行こうよ。ウェブサーバーアプリ + サーバーコード + アプリケーションコード + DB、つまりポケットベース++みたいに、デプロイ先にもなる。さらにAPEみたいなシステムと組み合わせて、同じファイルが全プラットフォームで読み込み・保存できるように。悪魔の笑い。めっちゃクールなハッキングだね！著者に拍手を送りたい。

└

_> https://github.com/blue-monads/potatoverse

└

アプリケーションが実行可能ファイルに状態を書き込むのは、基本的にSmalltalk（またはLisp）みたいなもんだね。個人的には、これはソフトウェアを書くための非常に強力な方法だと思う。

└

正確にはこのアイデアじゃなかったけど、昔、Rubyアプリを一つのファイルにまとめるためにSQLiteを埋め込みデータベースとして遊んでたことがある。これよりも直接的ではなかったけど、基本的にはすべての依存関係（.soファイルも含む）を、オーバーライドしたrequireから読み込む偽ファイルシステムにコンパイルして、実行時に.dataセクションから：memory:データベースに展開してた。1.8から1.9に変わった時にビルドシステムが変わって、更新する時間がなかったから終わっちゃった。これを基にしたバージョンでオーバーレイファイルシステムを持ち運ぶのは比較的簡単だと思う。大変な作業はもう終わってるし。

コピーされたメモリとマッピングされたメモリの状況が、この実験の唯一の障害だね。そうでなければ、ファイルフォーマットの統一は大きな前進になる。Windows（や古いUnixシステムの一部）で使われるPE/COFF実行可能ファイルフォーマットは、実はリレーショナルデータベースでもある。 .NETアセンブリフォーマットも同様にリレーショナルデータベースだよ。ホイールが何度も再発明されてるね。

そうそう！これ、ずっと頭の片隅にあったんだ。あと、他のコメントでも指摘されてるけど、ファイルに（自己修正可能な）Lispイメージや、組み込みの仮想ファイルシステム、アプリケーションが使いたい（ランタイムで修正可能な）追加テーブルが含まれてるといいよね。SQLiteの動的リンクがELFの動的リンクと基本的に互換性があるのはすごいと思う。うまくいけば、著者が提案してるように、AppImagesのほとんどの使用をもっと効率的なフォーマットに置き換えられるかもしれない。著者が直接テキストページをmmapできないって言ってたから、SQLiteのBLOB内のセクション内容を圧縮するオプションはどうかな？二つの拡張機能を考えてて、SQLiteの実行可能ファイルを本当にユニークにすると思う。まず、関数やフックをもっと直接的にパッチできるリンク拡張。ホストSQLiteが拡張可能と定義するシンボルのためにBEFORE/AFTER/REPLACEフックを定義するプラグインSQLiteを想像してみて。次に、ランタイムでの再リンク。これはアプリケーションの著者の協力が必要になるけど、データベースを編集して依存関係を変更したりプラグインをロードしたりするのを想像してみて。インタープリタがそれを自動的にバックグラウンドでマッピングするんだ。次回、ウェブサーバーがaccept()を呼ぶときには、新しいバージョンのハンドリング関数が呼ばれる。

└

もちろん、ELFでメモリ内でこれを全部やることもできるけど、誰もやらないし、そのためのツールも書かれてないんだよね（私が知ってる最もマイナーなツールはld -rで、これは2つ以上の.oファイルをリンクして新しい.oファイルを生成するもので、実行可能ファイルにはならない）。

実行可能ファイルがデータベースでもあるってことは、バグがリレーショナルになるってことだね。セグフォルトの代わりに外部キー制約違反が出る。

オブジェクトファイルをリレーショナルDBとして見ることには納得できるけど、なんでSQLiteなの？オブジェクトファイルの上に仮想テーブルの抽象化を使ったSQLクエリエンジンじゃダメなの？SQLiteの機能のほとんどは、クエリエンジンの一部を除いて、どうやって適用されるのかが見えないんだよね。著者がオブジェクトファイルにスキーマメタデータを含める理由を主張したいなら、やっぱりSQLiteじゃなくてもよくない？なんか、好きなハンマーの使い道を探してる人に見えるな（すごく便利なハンマーだとは思うけど）、新しい改善されたオブジェクトファイルフォーマットがどうなるかを真剣に探求しているわけじゃないみたい。まあ、それは全然悪くないけどね。

└

sqliteはfopenの素晴らしい代替品だね。ただ、Cインターフェースはもっと冗長だけど。

フォーマット自体は非常に簡潔で、ディスクスペースやネットワーク帯域幅が極端に限られていた世界のために設計されている。フォーマットを変更するのは難しく、セクションをゼロにして新しいものを追加しなければならないことが多い。しかも自己記述型のスキーマはない。ELF自体は非常に一般的なフォーマットで、データのセクションは慣習的に特定の方法で解釈されるが、フォーマット自体はそれを強制しない。これは次のような素晴らしいユースケースのように聞こえる：1. ELFファイルをSELFファイルに 2. SELFファイルを修正 3. SELFファイルをELFファイルに

Hacker Newsで議論の続きを見る

ハクソク