【ITニュース解説】Why I Chose SQLite Over Postgres

ある開発者が「Librarian」というプロジェクトを進める中で、データの保存方法について重要な選択をした経緯が示されている。Librarianは、個人のEPUB形式の電子書籍コレクションを管理し、書籍のテキストを抽出し、それを小さな塊（チャンク）に分け、AIが理解しやすい形式（埋め込み）に変換し、ユーザーが書籍の内容について質問できるようなローカルアプリケーションだ。このプロジェクトでは、書籍のメタデータ、各章の内容、テキストチャンク、埋め込みデータ、要約、タグ、処理の状態など、多岐にわたる情報を効率的に保存する必要があった。

最終的にこの開発者が選んだのはSQLiteというデータベースである。PostgreSQLのような他の強力なデータベースが存在する中でSQLiteを選んだ背景には、Librarianというアプリケーションの独自の特性が深く関わっている。PostgreSQLは並行して多数のユーザーがアクセスするクラウドアプリケーションに適した、非常に高機能なデータベースであり、並行処理、サーバープロセス、ベクトル検索を扱うpgvectorのような機能、成熟したデータ移行ツール、データの複製オプションなど、多くの優れた機能を持っている。しかし、Librarianはそうした一般的なクラウドアプリケーションとは性質が異なっていた。

Librarianの最も重要な点は、それが個人のコンピューター上で動作する「ローカルファースト」なアプリケーションであるということだ。電子書籍ファイルはユーザーのローカルフォルダに保存され、アプリケーションによる解析や埋め込みの生成も全てローカルで行われる。このアプリケーションは、特定の個人の電子書籍コレクションを検索可能にするために作られており、複数のユーザーが同時に利用することはない。ユーザーアカウントも存在せず、多くのウェブサーバーが同じデータに書き込むような状況も発生しない。書籍の取り込み作業は、新しい本を追加した際に一時的に集中するが、その後は主に読んだり検索したりする操作が中心となる。このようなワークロードは、多数の人が常に書き込みを行うAPIとは大きく異なる。

このようなLibrarianの特性を考えると、SQLiteは非常に自然な選択肢だった。SQLiteは単一のローカルファイルとして機能し、追加のデータベースサーバーを起動する必要がない。データベースへの認証情報を管理したり、ネットワーク接続を気にしたりする必要もないため、運用に関する手間がほとんどかからない。アプリケーションが起動しない原因が、別のデータベースサービスの問題であるといった心配も無用である。また、その性能も特筆すべき点だ。個人のローカルライブラリに対する一般的なリレーショナルクエリにおいては、SQLiteは驚くほど高速に動作する。アプリケーションに組み込まれるため、ネットワークを介したデータ通信の遅延がなく、読み込みが主体のローカルなワークロードをスムーズに処理できる。開発者が遭遇した速度のボトルネックは、データベースの通常の操作ではなく、大量の埋め込みデータに対して「コサイン類似度」を計算する部分（NumPyを使用）であったと推測されている。PostgreSQLが優れていることは認識しつつも、Librarianの用途には機能が過剰であると感じられた。

Librarianの最初のバージョンを開発する上での真の要件は、「検索ループ全体が実用的に機能するかどうか」を証明することだった。具体的には、乱雑なEPUBファイルを確実に処理できるか、引用に必要な情報を保持できるか、ローカルで生成した埋め込みが役立つか、そして自分の書籍に対して質問することで実際に有用に感じるか、といった点である。これらの検証課題は、初めから本番環境レベルのデータベースサーバーを導入したとしても、本質的に解決が容易になるわけではなかった。SQLiteは、書籍の記録、生テキスト、チャンク、ベクトル、要約、ジョブの状態などを一時的に保存する場所を提供し、開発者はより核心的な問題に集中できた。基本的なループが動作するようになってから、ベクトル検索の速度が問題であることが明らかになったが、これはデータベース全体の問題ではなく、検索インデックスに関する問題であると判断された。そのため、開発者はSQLiteをデータの「真実の源」として維持しつつ、ベクトル検索のボトルネックを解消するためにOpenSearchのような別の専門的な検索インデックスを追加するという柔軟なアプローチを採用した。これにより、プロジェクト全体を早期に複雑な分散システムへと変えることなく、必要な部分だけを改善できたのである。

もしLibrarianが、クラウド上で書籍データを管理するような製品であったなら、PostgreSQLが選択された可能性が高い。これは、複数のデバイスから利用できるホスト型サービス、データ同期機能、ユーザーアカウント、コレクションの共有、ウェブアプリケーションからのアクセスなど、全く異なる要件を持つためだ。その場合、マネージドPostgreSQLデータベースは、耐久性のあるリモートストレージ、並行アクセス、バックアップ、データ移行、監視機能など、クラウドサービスを運用するために必要な全ての機能を提供してくれるだろう。SQLiteの最大の強みである「データとアプリケーションがユーザーのコンピューター上で一緒に存在する」という点が、クラウドサービスでは逆に扱いにくい点となる。しかし、開発者はこのプロジェクトをクラウドサービスにする意図はなかった。Librarianは、RAG（Retrieval Augmented Generation）の仕組みを学び、自分の電子書籍コレクションを検索し、質問できるという個人のニーズを満たすために作られたものだからだ。また、著作権の観点からも、実際の書籍データをクラウドに置くことは好ましくないという考えもあった。

データベースの選択は、特定の技術に絶対的に固執するものではなく、開発するプロジェクトの具体的な要件に合わせて柔軟に行うべきであるという考え方が示されている。SQLiteは、ローカルファーストでシングルユーザーのツールであり、その核となる機能の検証段階にあるLibrarianにとって、適切な規模のデータベースだった。それはプロジェクトの開始を容易にし、データの検証を容易にし、プロジェクト全体の移動も容易にした。もし将来的に要件が変わり、本当にクラウドでデータをホストする必要がある製品を開発するならば、その時はPostgreSQLが有力な選択肢となるだろう。Librarianは、そのような製品になる必要はなかったのである。