SQLiteにRust風「エディション」が必要な理由
原題: SQLite should have (Rust-style) editions
なぜ重要か
SQLiteはモバイル・組み込み・サーバー問わず世界で最も広く利用されるDBエンジンであり、デフォルト安全化の議論は業界全体のデータ品質向上に直結する。
ブログ「mort.coffee」は2026年7月15日、SQLiteのデフォルト設定に重大な問題があると指摘した。外部キー制約が無効、型チェックが緩い、WALモード非採用などを挙げ、後方互換性を維持しつつ安全な挙動に切り替えられるRust言語のエディション制度に倣った仕組みをSQLiteに導入すべきと主張している。
エンジニアのMort氏は個人ブログで、SQLiteが組み込みデータベースとして広く普及している一方、そのデフォルト設定が開発者を落とし穴に誘導すると詳述した。
最大の問題として挙げられたのが外部キー制約の無効化だ。他のRDBMS（PostgreSQL、MySQLなど）では外部キーが標準で機能するが、SQLiteでは「PRAGMA foreign_keys = ON;」を明示しない限り制約が無視される。記事ではBobのユーザーアカウントを削除した後、SQLiteのROWID再利用アルゴリズムによって新規ユーザーAliceが同一IDを取得し、Bobの古い投稿を「継承」してしまう具体的なシナリオをコードで示した。エラーすら発生せず、データの不整合が静かに進行する点が特に危険だと強調した。
次に型システムの問題を取り上げた。SQLiteはNULL・INTEGER・REAL・TEXT・BLOBの5種類の型を持つが、列の型定義はあくまで「型アフィニティ（親和性）」に過ぎず、INTEGER列に文字列を挿入しても拒否されない。これも「PRAGMA strict = ON;」または「CREATE TABLE … STRICT;」で厳格化できるが、デフォルトは緩いままだ。
Mort氏はこうした問題の解決策として、Rustのエディション制度に着目した。Rustは言語に破壊的変更を加える際、既存コードとの互換性を保ちながら新しい挙動をオプトインできる「エディション」単位のバージョン管理を採用している。SQLiteにも同様の仕組みを導入すれば、「PRAGMA edition = 2;」のような形で安全なデフォルトを有効化でき、既存アプリケーションへの影響を最小化しつつ新規プロジェクトでは健全な設定から始められると提案した。