導入（問題提起）

Webシステム開発に着手するとき、最初のつまずきが「データベースは何を選ぶべきか？」です。最初から“大規模”前提で選ぶと、学習コスト・セットアップ・運用が重くなり、MVPの速度が落ちます。一方で、安易に選んだDBが成長後のボトルネックになり移行で苦労することも。現実解は「小さく始め、移行しやすい前提で設計する」ことです。

本記事では、業務システムの初期構築〜成長局面でのDB選定と移行の考え方を、SQLite / MySQL / PostgreSQLの3択に絞って解説します。Pythonでの実装観点（ドライバ、マイグレーション、接続プール）や、Excel Web化からのステップアップにも触れます。

課題の詳細説明

中小規模の内製開発で直面しがちな課題を整理します。

  • どのDBを選ぶべきか判断できない

    • - 用語やベンチマークの前提が合わず、判断材料が抽象的

  • 移行時のダウンタイムが怖い

    • - 既存のExcel/Accessや運用中のアプリを止められない

  • 運用・バックアップに不安がある

    • - スナップショット、ポイントインタイムリカバリ、監査要件などが不明確

  • 成長時のスケール・機能の見通しが持てない

    • - トランザクション一貫性、全文検索、地理情報、分析の要否が読めない

解決方法（使い分け指針）

結論から言うと、以下の順で検討するのがコスパ最強です。

  • SQLite（最初の一歩）

    • - 単一サーバ/単一プロセスでのPoCや小規模運用に最適 - 導入最速、バックアップ容易（ファイルコピーで退避） - テストが圧倒的に速く、スキーマ実験がしやすい

  • MySQL（水平展開や周辺ツールの豊富さを重視）

    • - マネージド（RDS等）を選べば運用負荷を低下 - レプリケーション/パーティショニング/セカンダリ参照など拡張しやすい - SaaS、EC、受発注などの典型業務システムと相性が良い

  • PostgreSQL（機能と厳格な整合性を重視）

    • - ウィンドウ関数、CTE、JSONB、行レベルセキュリティ、拡張（PostGIS など）が強力 - トランザクション一貫性・複雑なクエリ・分析寄り要件に強い

「今の要件（6〜12か月）」と「1〜2年後の規模・複雑性」から逆算し、初期はSQLiteで速度最優先、早期にMySQL/PostgreSQLへ計画的に移行できるようスキーマとコードを整えておくのが現実解です。

具体例

ユースケース別に、どれを選ぶかの指針を挙げます。

  • 問い合わせ/予約/簡易CRMのMVP：まずSQLite

    • - 1台のアプリサーバ上で高速に回せる。バックアップはファイルコピー＋世代管理

  • 社内ポータル＋小規模ワークフロー：SQLite→MySQL

    • - 同時接続やレポート負荷が増えたらMySQLへ。マネージドを使い運用負荷を回避

  • 在庫/受発注/請求のトランザクション重視：MySQLまたはPostgreSQL

    • - 取引一貫性と参照負荷のバランスで選ぶ。分析を重視するならPostgreSQL

  • 地理情報や複雑検索、JSON運用：PostgreSQL

    • - PostGISや全文検索（pg_trgm）を活用

技術的な解説

Pythonでの実装・移行を念頭に、最小構成の断片を示します。


-- 可能な限りベンダー非依存のANSI SQLでスキーマ定義
CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE,
  created_at TIMESTAMP NOT NULL
);


# SQLAlchemyでDBベンダー差分を吸収（接続文字列を切替可能に）
from sqlalchemy import create_engine, text

def engine(db_url: str):
    return create_engine(db_url, pool_pre_ping=True, future=True)

def get_user_count(db_url: str) -> int:
    with engine(db_url).connect() as conn:
        return conn.execute(text("SELECT COUNT(*) FROM customers")).scalar()


# Alembicでマイグレーション管理（移行に強くなる）
# alembic.iniに接続先を記述し、環境ごとに切替
# コマンド例: alembic revision -m "add index"; alembic upgrade head


-- PostgreSQL でのみ使う拡張はマイグレーションに明記
-- 例: 行レベルセキュリティ（RLS）
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY by_owner ON orders USING (owner_id = current_setting('app.user_id')::int);

移行時は「データ移送」「スキーマ互換」「アプリ修正」「リハーサル」の4点を押さえます。CSV/NDJSONで段階移送し、アプリは接続先と方言差分を極小化（SQLAlchemy/クエリ分離）しておくと安全です。

導入の流れ

安全に小さく始め、将来の移行コストを抑える段取りです。

  1. 企画/要件（1週）

    2. - データの種類・トランザクション量・レポート頻度を見積もる - 6〜12か月のMVPはSQLiteでよいかを判断（Excel Web化の範囲も確認）

  2. 設計/PoC（1〜2週）

    3. - SQLiteでスキーマ・ETL・APIを実装。性能・同時接続の上限を試す - ベンダー依存の構文を避け、移行しやすい書き方に寄せる

  3. 実装/運用（2〜4週）

    4. - バックアップ（世代・整合・復旧手順）を確立 - 監査ログ・RBACを最初から入れる（業務システムの基本）

  4. 成長/移行（必要時）

    5. - リハーサル→短時間切替（リードオンリーモード）→本番切替 - アプリの接続先切替、接続プール/タイムアウト調整

まとめ

DBは「最小で始め、移行を前提に設計する」のが中小規模のWebシステム開発における最短距離です。SQLite→MySQL/PostgreSQLという王道ルートを取り、Pythonの標準的なツール（SQLAlchemy/Alembic）で差分を吸収すれば、初速と将来性の両立が可能です。業務システムの“真実の源泉”を整え、Excel Web化の次のステップに進みましょう。

DB選定・移行計画のご相談は以下からどうぞ。

Webシステム開発のご相談は monou まで ※お問い合わせはこちら