バックエンド開発 on Dev TLDRLSS

SQLiteの気まぐれに騙されるな！動的型の罠とは？なぜ ALTER TABLE は不完全なのか？Node.jsで防御的プログラミングを行いスムーズなテーブル移行を実現する方法

Tue, 19 May 2026 18:10:00 +0800

リサイクルボックスに「ペットボトル専用」と書かれたラベルが貼ってあるのに、誰かが紙くずを投げ入れても、一言の抗議もなく静かに受け入れている様子を想像してみてください。

これが、開発者が初めて SQLite の型システムに出会ったときの背筋の凍るような体験です。

型が正しくなければ入国を即座に拒否する PostgreSQL のような厳格な税関スタイルに慣れていると、SQLite の気まぐれさ（ルーズさ）に人生を疑いたくなるかもしれません。

さらに恐ろしいことに、テーブル構造を変更 しようとすると、こう告げられます。

「テーブルを直接変更することはできません。新しい家を建て、家具を移動させてから、古い家を爆破してください。」

SQLiteの内部には5つのストレージクラスしかない

CREATE TABLE でどれほど華やかな型名（VARCHAR(255)、BIGINT、DECIMAL）を宣言しても、SQLite の内部が認識するのは以下の 5つのストレージクラス だけです。

ストレージクラス	説明
NULL	空値
INTEGER	整数（数値の大きさに応じて自動的に1〜8バイトを占有）
REAL	浮動小数点数（固定8バイト）
TEXT	文字列（デフォルトはUTF-8エンコーディング）
BLOB	バイナリデータ（入力されたまま保存）

カラムに設定する型は、SQLite にとって 単なる「推奨」であり、「強制ルール」ではありません。

これを 「型アフィニティ（Type Affinity）」 と呼びます。SQLite はデータを推奨される型に変換しようと試みますが、変換できない場合はエラーを吐かずに元のデータをそのまま挿入します。

カラムに設定する型は、SQLite にとって 単なる「推奨」であり、「強制ルール」ではありません。

最も陥りやすい3つの型の罠

罠1：ネイティブのBooleanがない

SQLite にには Boolean型がありません。True と False は整数 1 と 0 でしか表現できません。

Node.js を使って SQLite からデータを取得すると、true や false ではなく、数値の 1 または 0 が返ってきます。

if (user.is_admin === true) のようなチェックを直接行うと、永遠に真になりません。

罠2：Date/Time型がない

SQLite には 日付時刻型がありません。時間は以下のように保存するしかありません。

保存方法	例	メリット・デメリット
TEXT（ISO-8601 文字列）	`'2026-05-19T18:00:00Z'`	最も推奨。視認性が高く、将来 PostgreSQL に移行する際もスムーズに変換可能
INTEGER（Unixタイムスタンプ）	`1747656000`	フットプリントは小さいが、人間には読めない

日付を 2026/5/19 午後6時 のような独自のカスタム形式で保存してはいけません。将来のデータマイグレーションで悲劇が起こります。

罠3：INTEGERカラムに文字列を挿入してもエラーにならない

PostgreSQL では INTEGER カラムに文字列を挿入すると即座にエラーになります。しかし SQLite は静かに変換を試み、失敗した場合はそのまま受け入れます。

これは、汚いデータが静かにデータベースに紛れ込む 可能性を意味します。ある日、プログラムが予期しない型を受け取ってクラッシュしたときに初めて、問題に気づくことになります。

防御的プログラミング：気まぐれなデータベースに厳格な態度で臨む

SQLite のルーズさに直面したとき、Node.js 開発では 厳格な防御メカニズム を構築しなければなりません。

防御レベル	ツール	役割
コンパイル時のガード	TypeScript	コード記述段階で誤った型をキャッチする
API入口での検証	Zod	受信するデータを厳格に検証する（ageが必ず数値であることを保証する）
内部的な型キャスト	Prisma / Drizzle ORM	SQLiteとPostgreSQL間の型の違いを自動的に処理する

「データ検証の門番」 をデータベース層から Node.js アプリケーション層に移動させることが、SQLite の開発スピードを活かしつつ、将来の拡張性を確保するための重要な戦略です。

ORM を使用する場合、コード内で type: 'boolean' と宣言しておけば、ORMが SQLite への保存時に自動的に 1/0 に変換し、読み込み時には true/false に自動変換してくれるため、底層の型の違いを完璧に隠蔽できます。

ALTER TABLEは不完全：何が変更できて、何ができないのか

SQLite がサポートするテーブル構造の変更は非常に限定的です。

操作	サポート状況
カラムの追加（`ADD COLUMN`）	はい
カラム名の変更（`RENAME COLUMN`）	はい
カラムの削除（`DROP COLUMN`）	はい（比較的新しいバージョンのみ）
テーブル名の変更（`RENAME TO`）	はい
カラム型の変更	いいえ
`UNIQUE`、`NOT NULL` 制約の追加/削除	いいえ
プライマリキーの変更	いいえ
外部キーの変更	いいえ

「サポートされていない」変更を行う必要がある場合、SQLite は 「再作成して移行する」 戦略を実行するよう要求します。

再作成＆移行の4ステップ：SQLite流のテーブルアップグレード方法

直接変更できないため、公式ドキュメントが推奨する標準的なアプローチは、新しい家を建て、家具を移動し、古い家を爆破し、新しい表札を掲げる ことです。

ステップ	アクション	説明
1	新しいテーブルの作成	`CREATE TABLE users_new (...)` を正しい構造で作成
2	データのコピー	`INSERT INTO users_new SELECT ... FROM users`
3	古いテーブルの削除	`DROP TABLE users`
4	テーブル名の変更	`ALTER TABLE users_new RENAME TO users`

これら4つのステップは 一気に行う 必要があり、途中で停電やアプリケーションのクラッシュが発生するとデータ損失につながります。

アップグレードでデータを失わないための確保：2つの安全防衛線

防衛線1：物理的な防衛、ファイルを直接コピーする

SQLite は本質的に単なるファイルです。スキーマ変更を実行する前に、単純に .db ファイルをバックアップとしてコピーしておくだけで十分です。

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

万が一失敗した場合は、ファイルを元に戻すだけで一瞬で復元できます。これは他の巨大なデータベースにはない強みです。

防衛線2：トランザクションによるカプセル化、データベースのタイムマシン

すべての移行ステップを単一の Transaction 内でカプセル化します。いずれかのステップが失敗した場合、プロセス全体が 自動的にロールバック され、何事もなかったかのように復元されます。

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('テーブルのアップグレードに成功しました');
} catch (error) {
  console.error('アップグレードに失敗しました。データは安全に復元されました：', error.message);
}

「バックアップファイル＋トランザクションバインド」 が、データベースマイグレーションのエアバッグとなります。

厳格な態度でルーズな SQLite を乗りこなす

気まぐれな SQLite を 厳格なアプリケーション層アーキテクチャ で制御することで、将来の技術的負債を回避しながら、その超高速な開発スピードを存分に享受できます。

SQLiteの型システムは非常にルーズであり、ALTER TABLE にも多くの制限があります。

しかし、Node.js 側で TypeScript の型チェック＋ Zod のバリデーション＋ ORM の抽象化 をしっかりと行い、物理バックアップ＋トランザクション の安全戦略と組み合わせることで、SQLite がもたらす開発効率を安心して享受しつつ、将来 PostgreSQL に移行するための道筋を整えることができます。

Reference

すべてに PostgreSQL を使うのはやめよう！SQLite の組み込み型アーキテクチャとゼロ設定のメリットとは？SQLite の限界はどこにある？SQLite と PostgreSQL、どちらを選ぶべき？

Tue, 19 May 2026 18:00:00 +0800

毎日開くブラウザ、スマホのメッセージアプリ、あるいはデスクトップ上のメモツールの中に、すべて同じ軽量データベースが隠されていると考えたことはありますか？

サーバーソフトウェアのインストールは不要で、アカウントやパスワードの設定も要らず、インターネット接続すら必要ありません。それは単なる ファイル であり、ハードディスクに静かに横たわり、いつでもサービスを提供する準備ができています。

この控えめな存在こそが、SQLite です。

SQLite とは？世界で最も広く導入されているデータベース

SQLite は、C 言語で書かれた 組み込み型関係データベースエンジン です。

独立したサーバープロセスを持たず、アプリケーションに直接組み込まれて動作します。

これは、お馴染みの PostgreSQL や MySQL とはまったく異なります。従来のデータベースは 独立して動作するサーバー であり、プログラムは ネットワークプロトコル（TCP/IP） を介してそれと「通信」する必要があります。

しかし、SQLite は違います。それは単なるコードのブロックであり、アプリケーションの内部で直接実行され、ハードディスク上の .db ファイルを読み書きします。

比較基準	SQLite（組み込み型）	PostgreSQL（クライアント・サーバー型）
動作モード	アプリケーションに直接組み込み、独立サーバーなし	独立したサーバープロセス、ネットワーク接続経由
設定要件	ゼロ設定、インストール不要、認証情報不要	インストール、アカウント/パスワード設定、ファイアウォールが必要
データ保存	単一のクロスプラットフォームファイル	サーバーディレクトリ配下の複数ファイル
バックアップ方法	そのファイルを直接コピーするだけ	pg_dump などの専用ツールが必要

まさにこの 「プラグアンドプレイ」 の特性により、SQLite は世界で最も広く導入されているデータベースエンジンとなりました。

Android や iOS オペレーティングシステム、Chrome や Firefox ブラウザから、Adobe Lightroom、WhatsApp、さらには Airbus A350 の飛行システムに至るまで、いたるところに存在しています。

Node.js での SQLite の使用

Node.js 開発者であれば、SQLite の使用は非常に簡単です。コンピューターにデータベースサーバーソフトウェアをインストールする必要はなく、npm パッケージをインストールするだけで開始できます。

現在、業界で最も一般的に使用されている選択肢：

パッケージ名	特徴	推奨されるシナリオ
`sqlite3`	最も老舗、非同期 API をサポート	多数 of 非同期タスクを同時に処理する必要がある場合
`better-sqlite3`	優れたパフォーマンス、直感的な API 設計、極めて高速	第一推奨、開発効率と実行速度を追求する場合

better-sqlite3 を使ってデータベースを作成し、クエリを実行するのに 5 分もかかりません：

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

ファイルが存在しない場合、better-sqlite3 が 自動的に作成します。

SQLite は想像以上に強力な SQL 構文をサポートしている

多くの人は SQLite が非常にシンプルだと思っていますが、実際には以下のような高度な機能を含む、標準的な SQL 構文の大部分をサポートしています：

構文カテゴリ	サポート項目
基本操作	`SELECT`、`INSERT`、`UPDATE`、`DELETE`
データ定義	`CREATE TABLE`、`CREATE INDEX`、`CREATE VIEW`
高度なクエリ	`WITH`（再帰的 CTE）、ウィンドウ関数（Window Functions）
衝突処理	`UPSERT`（`INSERT ... ON CONFLICT DO UPDATE`）
JSON 処理	`json_extract`、`json_array`、`json_object` などの組み込み関数
トランザクション制御	`BEGIN`、`COMMIT`、`ROLLBACK`、`SAVEPOINT`
結合クエリ	`INNER JOIN`、`LEFT JOIN`、`RIGHT JOIN`、`FULL OUTER JOIN`

SQLite のコア哲学は「スモール・イズ・ビューティフル」 です。日々必要な SQL 機能の大部分をサポートしつつ、極限まで軽量さを維持しています。

SQLite の限界はどこにある？

軽量さには代償が伴います。もし SQLite を レジが 1 つしかない個人経営の雑貨店 に例えるなら、PostgreSQL は 50 個のレジを備えたコストコ です。

1. 書き込みの渋滞

SQLite はデータを書き込む際、データベースファイル全体を ロック します。

トイレが 1 つしかないレストラン を想像してみてください。100 人が外で同時にメニューを見る（読み取り）ことはできますが、誰か 1 人が入ってドアに鍵をかける（書き込み）と、他の全員は並んで待つしかありません。

WAL モード（Write-Ahead Logging） を有効にすれば、同時読み書きのパフォーマンスは向上しますが、本質的に複数のスレッドが異なるデータ行に同時に書き込むことはできません。

2. 複数サーバー間での共有不可

SQLite の本質は物理ファイルです。システムを複数のサーバーにデプロイする場合（水平スケーリング）、これらのサーバーで 同じファイルを安全に共有することはできません。

3. きめ細かな権限管理の欠如

SQLite には「ユーザーアカウント」という概念がありません。OS レベルでその .db ファイルを読み取れる人であれば、誰でもすべてのデータを閲覧・変更できます。

厳格な個人情報監査が必要なビジネスシステム において、这是無法接受的。

SQLite vs. PostgreSQL：技術選定の意思決定

ツールに優劣はなく、適しているかどうかがすべてです。判断を助けるための究極のチェックリストを紹介します：

質問	回答が「はい」 → SQLite を選択	回答が「いいえ」 → PostgreSQL を選択
バックエンドサーバーは 1 台だけ、またはローカルのみで動作していますか？	はい	いいえ（水平スケーリング、複数マシンが必要）
システムの動作は読み取りが圧倒的に多く、高頻度の同時書き込みはありませんか？	はい	いいえ（同時書き込みが多発する）
きめ細かな権限管理や、高度なインデックス機能は不要ですか？	はい	いいえ（高度な機能に強く依存している）

より具体的なシナリオ比較：

シナリオ	推奨される選択肢	理由
デスクトップソフト、スマホアプリ、IoT 機器	SQLite	データがデバイスに追従し、インストール不要
個人ブログ、紹介用ホームページ	SQLite	参照が多く書き込みが少ないため、サーバー維持費を削減可能
迅速なプロトタイプ開発、デモ	SQLite	ファイルを作成するだけで即座に開始可能
コミュニティフォーラム、EC サイト	PostgreSQL	高い同時書き込みが発生し、行レベルのロックが必要
複数サーバーへの分散デプロイ	PostgreSQL	複数マシン間でデータソースを共有する必要がある
医療、金融などの機密システム	PostgreSQL	ロールベースの厳格な権限管理が必要

あなたのデータベースはポケットのメモ帳か、それとも中央交換手か

データが 「シングルマシン、静的、単一の所有者」 であるなら、SQLite を選んで究極の軽快さと自由を享受しましょう。

データが 「クラウド、動的、高度なインタラクティブ」 であるなら、PostgreSQL に任せましょう。

SQLite のコア哲学は 「アプリケーション of 内部コンポーネント」 であるのに対し、PostgreSQL は 「システムアーキテクチャ of 独立した中心」 として位置づけられています。

次回、アーキテクチャの意思決定を行う際は、急いで PostgreSQL を持ち出す前に、まず自分自身に問いかけてみてください：

「私のデータベースは、ポケットのメモ帳ですか、それとも中央交換手ですか？」

答えがはっきりすれば、選択は自然と明らかになります。