【変態的圧縮】SQLiteを捨ててDBを「FST」化した結果、300倍に縮んだ話。2026年、データ構造の極北へ

【Geek Terminal：2026年5月11日配信】

「汎用性は、美学の敵だ」――そんな過激な思想を体現するかのようなプロジェクトが、いま世界の低レイヤーギークたちの間で熱狂的な議論を巻き起こしている。2026年5月現在、標準的なRDBMS（リレーショナルデータベース）であるSQLiteを完全に廃し、データ構造そのものを「FST（Finite State Transducer：有限状態トランスデューサ）」へと変換することで、データサイズを300倍に圧縮し、かつ検索速度を極限まで引き上げるという「狂気の実装」が注目を集めているのだ。

公式メディアでの正式なプレスリリースや商用化の発表は未だ確認されていないが、GitHubの深淵やRedditの限定的なサブレディット（r/BinarySorceryなど）では、この「DBをバイナリの迷宮へ封じ込める」手法の有効性を巡り、賛否両論の嵐が吹き荒れている。本稿では、この変態的アプローチの全貌と、背後にある技術的執念を深掘りする。

【事象の全貌と背景】：なぜ今、RDBMSを捨てるのか

2026年、私たちの身の回りには「巨大すぎるデータ」と「小さすぎるエッジデバイス」が溢れている。ローカルLLMのインデックス、膨大なIoTログ、そしてリアルタイムで更新され続けるベクトルデータ。これらをSQLiteのような、B-Treeをベースとした汎用DBで管理することに、一部のギークたちは限界を感じ始めていた。

SQLiteは素晴らしい。しかし、それは「汎用」であるがゆえに、インデックスのオーバーヘッド、ページ管理の冗長性、そしてSQLパーサーという「重い皮」を被っている。特に、読み取り専用に近い大規模な辞書データや、構造化されたログデータを扱う場合、SQLiteのファイルサイズは「数学的に見て無駄が多い」と彼らは断じる。これまでの課題は、圧縮率を高めると検索速度が落ち（gzip等）、検索速度を上げるとサイズが膨らむというトレードオフだった。この壁を「データ構造の置換」という暴力的な解決策で突破しようとするのが、今回のFST化プロジェクトだ。

【技術的ディープダイブ】：FST（有限状態トランスデューサ）という魔術

今回話題となっている手法の核心は、データを「行と列」ではなく、「有向非巡回グラフ（DAG）」として保持する点にある。FSTは、入力に対して出力を返すオートマトンの一種だが、これをデータ保持形式として利用すると、驚異的な共通部分の集約が可能になる。

具体的には、キーとなる文字列の「接頭辞（Prefix）」だけでなく「接尾辞（Suffix）」までもが数学的に共有される。例えば、「walking」「walked」「walks」というデータがある場合、従来のDBでは「walk」という文字列が何度も重複して記録されるが、FSTではこれらが一つのノード群へと圧縮される。さらに、今回のプロジェクトが「変態的」とされるのは、このFSTを単なるインメモリの辞書としてではなく、ディスク上のバイナリ構造として直接、ビット単位で最適化して自作している点だ。

検索速度においても、SQLのようにクエリをパースし、B-Treeを辿り、ページをロードする手順を一切踏まない。検索は「状態遷移」そのものであり、ポインタを辿るだけのO(n)（nはキーの長さ）で完結する。コミュニティの噂によれば、特定の静的データセットにおいて、SQLiteで1.2GBあったファイルが、FST化によってわずか4MBにまで圧縮され、かつ検索レイテンシがマイクロ秒以下に固定されたという。これは、2026年の産業界で注目されている「テンソルネットワークによるモデル圧縮（arXiv:2404.11277v2）」とも思想的に共鳴する、数学的極限への挑戦である。

【コミュニティの生々しい熱量と議論】：ライブラリ依存を拒む「自作派」の逆襲

Redditでは、このプロジェクトに対して「ついに本物のハッカーが帰ってきた」という称賛の声が上がる一方で、「実用性がない」という冷ややかな意見も飛び交っている。特に議論の的となっているのは、FSTの「不変性（Immutability）」だ。

FSTは構造上、一度構築したグラフに後からデータを「一行追加」することが極めて困難である。追加のたびにグラフ全体を再構築（リコンパイル）する必要があるため、動的な書き込みが発生する用途には向かない。これに対し、あるユーザーはこう反論した。「書き込みが必要ならSQLiteを使え。俺たちが欲しいのは、100GBの埋め込みデータを、スマートウォッチのVRAMにねじ込むための『究極の読み取り専用バイナリ』なんだよ」。

また、既存のライブラリ（Rustのfst crate等）を使わず、ビットパッキングやエンディアン制御まで自作する姿勢に対し、「車輪の再発明どころか、車輪の原子構造から再設計している」との評も。この「ライブラリ依存を拒絶し、数学という普遍的な言語だけでDBを再定義する」というギークの執念こそが、この熱量の源泉となっている。

【今後の展望とエコシステムへの影響】：汎用DBは「オワコン」になるか？

このFST化アプローチが一般化すれば、特定分野の「データベース」という概念は消滅し、代わりに「コンパイルされたデータバイナリ」が主流になる可能性がある。特に、ローカル環境で動作するAIエージェントの知識ベースや、モバイルデバイスの地図データ、言語辞書などは、もはや重厚なRDBMSを必要としなくなるだろう。

もちろん、すべてのDBがFSTに置き換わるわけではない。しかし、「データの保持形式そのものへの挑戦」は、ソフトウェア開発における「抽象化への甘え」を痛烈に批判している。今後は、用途に応じてデータ構造をスクラッチから「焼く（Compile）」という手法が、高度なパフォーマンスを求めるエンジニアの間で標準的なスキルセットとなっていくかもしれない。

「300倍の圧縮」という数字が、もし特定のデータセットに依存した過剰な噂であったとしても、このプロジェクトが示した「RDBMSという標準を捨てる勇気」は、2020年代後半のテクノロジー界における重要なパラダイムシフトの予兆と言えるだろう。ライブラリを叩く作業に飽きた者たちが、再びバイナリの深淵へと潜り始めたのだ。