Bun × SQLite：ORMを捨て、SQLの「物理的直感」で最速のバックエンドを構築する
現代のWeb開発において、我々は過剰な抽象化の代償を払わされすぎている。特に小〜中規模のバックエンド開発において、巨大なORMを導入し、その複雑なクエリビルダの仕様を学習し、実行時に発行される「意図しないSQL」に頭を抱える時間は、エンジニアの寿命を削る無駄なコストだ。
Bunは、`bun:sqlite`というモジュールをランタイムレベルで統合している。これは単なる「ライブラリ」ではなく、Node.jsの時代には考えられなかった、SQLiteをOSのプロセスのようにネイティブに扱うためのインターフェースだ。
今回は、ORMなしで爆速かつ堅牢なバックエンドを構築するための、テックリード視点の実践知を共有する。
—
1. なぜ「SQL直書き」が実は最強のアーキテクチャなのか
ORMはテーブル構造の変化をコードに同期させる際、しばしば「マイグレーションの衝突」や「N+1問題」をブラックボックス化する。対して、`bun:sqlite`を用いたSQL直書きは、以下の3つの利益をもたらす。
1. 実行計画の可視化: SQLをそのまま書くことで、開発者は常にインデックスの効きを意識するようになる。
2. 型安全性へのショートカット: TypeScriptのテンプレートリテラル型を利用すれば、ORMの巨大なランタイムオーバーヘッドなしに、コンパイル時のチェックが可能になる。
3. IOの極小化: `bun:sqlite`はNode.jsの`better-sqlite3`をC++で再実装したような速度を誇る。中間層を通らないため、レイテンシは物理限界に近い。
—
2. 開発効率を極限まで高める「実用型」設定とツールチェーン
Bun環境をチームの標準にする際、ただインストールするだけでは不十分だ。以下の環境設定を徹底することで、チームの生産性は劇的に向上する。
VS Code神プラグイン
- SQLite Viewer: データベースファイル(`.sqlite`)をエディタ内で直接開き、実行計画を確認するための必須ツール。
- TypeScript SQL Template Literals: SQL文字列にシンタックスハイライトと補完を提供し、誤字を即座に検知する。
チーム共有設定 (`bunfig.toml`)
プロジェクトルートに配置する `bunfig.toml` は、全開発者のランタイム挙動を揃えるための「掟」だ。
bunfig.toml
チーム全体でランタイムの挙動を統一する
[run]
実行時のメモリリークを監視するためのプロファイル設定
smol = true
[test]
テスト実行時の並列度をCPUコア数に合わせることでCI時間を短縮
concurrency = 4
カバレッジ測定を標準化し、個人の環境差を排除する
coverage = true
—
3. 実装パターン：ORMを使わずに「型安全」を担保する
ORMなしで開発する場合、最も懸念されるのは「SQLのバリデーション」だ。ここで、`Zod`と`bun:sqlite`を組み合わせた「型安全レイヤー」を紹介する。
実装例：型定義とデータベース操作の分離
import { Database } from “bun:sqlite”;
import { z } from “zod”;
const db = new Database(“app.db”);
// 1. Zodによるスキーマ定義（入力と出力の型を確定させる）
const UserSchema = z.object({
id: z.number().int(),
username: z.string().min(3),
email: z.string().email(),
});
type User = z.infer
// 2. データベース操作関数（SQL直書き）
export const getUserById = (id: number): User | null => {
const query = db.prepare(“SELECT FROM users WHERE id = ?”);
const row = query.get(id);
// 3. バリデーションを通すことで、DBの値が不正でも実行時に即座に検知
return row ? UserSchema.parse(row) : null;
};
この手法の肝は、「DBから返ってきた生データを、ビジネスロジックに渡す前に必ずZodで検証する」という一点に尽きる。これにより、SQLの変更がコードに与える影響をコンパイル時（または実行時の境界線）で完全に制御できる。
—
4. プロの技術選定：CI/CDでの「破壊的変更」検知
チーム開発では、SQLのスキーマ変更が他メンバーのコードを壊すリスクがある。これを防ぐには、「テスト実行時に一時DBを作成し、マイグレーションを全適用する」というフローをCIに組み込むべきだ。
.github/workflows/ci.yml
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: oven-sh/setup-bun@v1
- run: bun install
# スキーマの整合性をテスト前に確認
- run: bun run db:migrate:check
# インメモリDBでテストを実行し、高速化を維持
- run: bun test
—
5. 最後に：ツールを使いこなすということ
BunやSQLiteは、単に「速いツール」ではない。これらは、開発者が「自分の書いているコードが、最終的にどうCPUに命令を出し、どうディスクを叩いているか」を意識させるための透明なアーキテクチャである。
ORMの巨大なスタックトレースを追いかける時間を、ビジネスロジックの磨き上げに充てろ。SQLという、30年以上変わらない最も強力なインターフェースを直に操ることで、あなたの書くバックエンドは、十年後も通用する「頑健なコード」へと進化するはずだ。
さあ、今すぐ `bun init` し、ORMの呪縛から解き放たれた真の爆速開発を体感してほしい。