SQLiteとは？組み込み型SQLデータベース入門

SQLite はプログラムに組み込むデータベース

MySQL、Postgres、SQL Server——名前を聞いたことがあるデータベースの多くは、独立したプログラムとして動きます。サーバーを起動し、ポートで待ち受け、アプリケーションがネットワーク越しに接続してクエリを投げる、というモデルですね。SQLite はこの仕組みをまるごと捨てています。

SQLite の正体はライブラリです。プログラムにリンクするだけで、ディスク上のたった 1 つのファイルに収まる SQL データベースが手に入ります。サーバーレスでポートも不要、デーモンも pg_ctl start もありません。アプリケーションが開くそのファイルが、そのままデータベース_そのもの_なのです。

sqlite3 mydata.db

このコマンドを実行すると、mydata.db というファイルが開かれる（なければ新規作成される）と同時に、SQL プロンプトが立ち上がります。テーブルも行もインデックスも、すべてこの 1 つのファイルに収まります。別のマシンにコピーすればデータベースごと持ち運べますし、ファイルを削除すればデータベースもまるごと消える、というわかりやすさです。

SQL をざっと眺めてみる

SQL の書き方自体は、他の RDBMS とほとんど同じです。MySQL や PostgreSQL を触ったことがあれば、ほぼ違和感なく書けるはずです。

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

標準的な SQL — CREATE TABLE、INSERT、SELECT、ORDER BY。普段の業務で実際に使う SQL 標準の機能はひと通り揃っていて、CTE、ウィンドウ関数、JSON 関数といったモダンな機能もちゃんと使えます。Postgres や MySQL との違いは、主に型の扱いと細かな構文のクセくらいで、これは後ほど取り上げます。

「組み込み」と「サーバーレス」の本当の意味

SQLite を語るときに必ず出てくる 2 つのキーワードがあります。ここでしっかり整理しておきましょう。

組み込み(embedded) とは、SQLite がアプリケーションと同じプロセス内で動くという意味です。データベース専用のプロセスは別に立ち上がりません。Python スクリプトで sqlite3.connect("data.db") を呼ぶと、SQL エンジンは Python プロセスの中で 動き、ファイルを直接読み書きします。

サーバーレス とは、インストール・設定・起動・セキュリティ対策・バックアップが必要なサーバーが存在しないということ。データベースを使い始めるまでの手順を比べてみましょう。

• Postgres: Postgres をインストール → サービスを起動 → ユーザー作成 → データベース作成 → pg_hba.conf を設定 → TCP で接続。
• SQLite: ファイルを開く。

差はこれだけです。できることは少なくなりますが、その代わり手間が圧倒的に少ない。

データベース全体がたった 1 つのファイル

ここが多くの人を驚かせるポイントです。ファイルフォーマットは公開されていて安定しているので、.db(あるいは .sqlite、.sqlite3 — 拡張子は単なる慣習です)ファイルに対して、こんなことができます。

• 同僚にメールで送る。
• git にコミットする(サイズが小さければ、ですが)。
• cp でコピーすれば、それだけで即席バックアップ。
• どんな OS でも、SQLite 対応ツールならそのまま開ける。

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

この1つのファイルに、テーブルもインデックスもスキーマもデータも、すべてが収まっています。ディスク上の SQLite データベースは、Windows、macOS、Linux、iOS、Android のいずれでもバイト単位で完全に同一です。フォーマットは非常に安定しており、米国議会図書館が長期データ保存用フォーマットとして推奨しているほどです。

あなたはすでに SQLite を使っている

今この記事を読んでいるデバイスの中にも、SQLite データベースは間違いなく数百個は存在しています。たとえば、こんなところで動いています。

• iOS や Android のシステムストレージ、そして両プラットフォームの多くのアプリ
• Firefox、Chrome、Safari(履歴、ブックマーク、Cookie)
• macOS(メール、写真、Dock)
• ローカルストレージを必要とする Linux デスクトップアプリの大半
• Skype、WhatsApp、Signal のチャット履歴
• Adobe Lightroom のカタログ、Dropbox のメタデータ、Steam のライブラリ

「世界で最も広く使われているデータベースエンジン」と呼ばれることもあり、これはおそらく事実です。理由はシンプルで、アプリにローカルの構造化ストレージが必要になったとき、SQLite が一番手軽な選択肢だからです。

SQLite が向いていないこと

SQLite はクライアント・サーバー型のデータベースではありません。別々のマシンで動く2つのプログラムが、ネットワーク経由で同じ SQLite データベースに接続することはできません。そもそも接続するためのネットワーク層が存在しないからです。そういう用途なら Postgres や MySQL を使うべきです。

書き込みの高並行処理にも向いていません。SQLite はファイル単位のロックを使っており(WAL モードでいくつか巧妙な最適化はありますが)、読み込みは多数を並列で処理できる一方、書き込みのコミットは同時に1つしか通りません。シングルユーザーのアプリや低トラフィックのサイトなら問題になりませんが、毎秒数千件の書き込みが走るマルチテナントの SaaS には不向きです。

ユーザー管理や権限管理の機能もありません。データベースへのアクセス権限は、ファイルへのアクセス権限そのものです。ファイルを読める人はデータも読めます。自分自身でデータベースファイルを所有するアプリなら問題ありませんが、共有のマルチテナント構成には向きません。

SQLite を選ぶ理由

得られるのはシンプルさ。引き換えに失うのは、たぶん必要にならないであろうスケーラビリティの余地です。

• セットアップ不要。 起動すべきサービスがありません。開発と本番でバージョンがズレることもありません。「データベースサーバーが落ちた」という障害自体がそもそも起きません。サーバーが存在しないので。
• 高速。 ほとんどのワークロード、特に読み込みが多いケースでは、ネットワーク越しのデータベースより SQLite のほうが速いです。クエリごとのソケット往復がないからです。
• 信頼性が高い。 とにかく徹底的にテストされています。SQLite プロジェクトはソースコードよりテストコードのほうが圧倒的に多く、フォーマット自体も2004年以来安定しています。
• パブリックドメイン。 商用利用も含めて完全に自由に使えます。読むべきライセンス文書すらありません。
• ポータブル。 1ファイルで、すべてのプラットフォームに対応。

ローカルアプリ、プロトタイプ、組み込み機器、CLI ツール、テストスイート、データ分析スクリプト、それから中小規模のウェブサイト。こうした用途では、SQLite はしばしば「本物のデータベース」への踏み台ではなく、正解 のデフォルト選択肢になります。

次回:SQLite と MySQL の違い

ここで自然に出てくる疑問が、もっと耳にする機会の多いデータベースサーバーと比べて SQLite はどうなのか、というものです。次回はまず MySQL を取り上げ、それぞれが得意とする領域と、目の前のプロジェクトにどちらが合うかの見極め方を解説します。