💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

2026 年のデータベース風景は二つの命題に集約される。第一に、**Postgres が API を制した**。新規 SaaS のデフォルト、AI エージェントが書くコードの標準方言、サーバーレスのキャッチフレーズ、あらゆる ORM の第一ターゲット — Neon、Supabase、Prisma Postgres、Xata、Render Postgres、Fly Postgres、Vercel Postgres(実体は Neon)、Crunchy Bridge、Tembo、Convex SQL まで、すべてが Postgres ワイヤープロトコルを話すかホストしている。第二に、**ClickHouse と DuckDB が分析を制した**。ClickHouse はペタバイト級クラウド OLAP の事実上の標準となり、DuckDB はノート PC・エッジ・ブラウザ・Lambda・Worker のどこでも動く "組み込み Snowflake" のポジションを確立した。その隙間で StarRocks・Doris・Druid・Pinot がリアルタイム OLAP を、Cassandra・Scylla・Aerospike・FoundationDB が超高 QPS ワークロードを、TiDB・CockroachDB・YugabyteDB・Spanner が分散 SQL を担う。

本稿は 2026 年 5 月時点の OLTP、OLAP、NewSQL、NoSQL、組み込み、ORM、そしてサーバーレス Postgres の経済学までを一枚に展開する。PostgreSQL 18 RC、MySQL 9.x、MariaDB 12、ClickHouse 24.x、DuckDB 1.x の実機能を押さえ、韓国・日本ビッグテックの運用事例も交える。

2026 年の全体像

* **Postgres**: Greenplum、Aurora Limitless、Citus、Neon、Supabase、PlanetScale Postgres まですべて PG の上に立つ。AI/ベクトル(`pgvector`)・時系列(`timescaledb`)・検索(`tsvector`)・地理(`postgis`)・キュー(`pgmq`)が一つのエンジンで動く。

* **MySQL/MariaDB**: Oracle MySQL 9、MariaDB 12、Vitess(現在は PlanetScale から分離)、TiDB がワイヤープロトコル互換性を維持。ただし新規採用は減速傾向。

* **OLAP**: ClickHouse Cloud、Snowflake、BigQuery、Databricks、Redshift Serverless、StarRocks、Doris、Druid、Pinot — そして「データレイク上の ClickHouse/DuckDB」パターンが圧倒的。

* **分散 SQL**: TiDB、CockroachDB 25、YugabyteDB、Spanner GA オンプレ、AlloyDB Omni、Aurora DSQL。

* **NoSQL**: Cassandra 5、ScyllaDB、Aerospike、DynamoDB、Mongo 8、Cosmos DB。

* **組み込み**: SQLite、libSQL/Turso、DuckDB、rqlite、Cloudflare D1、LiteFS。

* **開発者ツール**: Drizzle ORM が TS ORM の主流になり、sqlc が Go で、Diesel・SeaORM が Rust で、SQLAlchemy 2.x が Python で、GORM は依然 Go の第一線。

ACID と分離レベルの再確認

標準 SQL の分離レベルは 4 段階だが、実エンジンはさらに多くの亜種を実装する。

* **Read Uncommitted**: ダーティリード許容。ほぼ使われない。

* **Read Committed**: PostgreSQL/Oracle のデフォルト。コミット済みデータのみ。

* **Repeatable Read**: MySQL InnoDB のデフォルト。同一トランザクション内で同じクエリは同じ結果。

* **Serializable**: PostgreSQL は SSI(Serializable Snapshot Isolation)を実装。

* **Snapshot Isolation**: Oracle、SQL Server、CockroachDB の事実上の標準。

CockroachDB と Spanner は外部一貫性(external consistency)または strict serializability を保証するために TrueTime または hybrid logical clock(HLC)を使用する。

MVCC とレプリケーショントポロジー

PostgreSQL の MVCC はタプルバージョンを同じページに置き、`xmin`/`xmax` のトランザクション ID で可視性を判定する。結果として VACUUM が必須。

MySQL InnoDB は以前のバージョンを undo ログに別途保存する。Postgres と異なり、専用 purge スレッドがバックグラウンドで動く。

レプリケーショントポロジー:

* **シングルリーダー(非同期)**: 既定の Postgres/MySQL。リーダーから非同期でフォロワーに伝播。

* **シングルリーダー(同期)**: `synchronous_standby_names` で 1 つ以上のフォロワーが ACK しないとコミットしない。

* **マルチリーダー**: MySQL Group Replication、BDR、CockroachDB。

* **リーダーレス(クォーラム)**: Cassandra、Scylla、DynamoDB。

-- PostgreSQL 18 論理レプリケーション v2: 双方向 + シーケンス同期

CREATE PUBLICATION sales_pub

FOR TABLE orders, customers, products

WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = true);

CREATE SUBSCRIPTION sales_sub

CONNECTION 'host=primary.internal dbname=app user=replicator'

PUBLICATION sales_pub

WITH (copy_data = true, streaming = 'parallel', origin = 'any', two_phase = true);

-- シーケンスも 18 から自動同期

ALTER SUBSCRIPTION sales_sub REFRESH PUBLICATION SEQUENCES;

カラム vs ロウストレージ

OLTP は行単位のアクセスが多く行ストレージ(InnoDB、Postgres heap)が有利、OLAP は列単位の圧縮が決定的でカラムナ(ClickHouse MergeTree、Parquet、Apache ORC、DuckDB native、Snowflake micro-partition)が有利。ClickHouse は LZ4/ZSTD に加え、Gorilla、Delta、DoubleDelta のような時系列特化圧縮も持つ。

ベクトル化実行(vectorized execution)は一度に 1024 個(またはそれ以上)のタプルを SIMD で処理する。ClickHouse、DuckDB、Photon(Databricks)、Velox、Snowflake はすべてこのパターン。

クエリオプティマイザ

PostgreSQL のプランナは CBO(Cost-Based Optimizer)に RBO ヒューリスティックを一部混ぜたハイブリッド。`pg_stat_statements`、`pg_hint_plan`、`auto_explain` が運用の三種の神器。

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON, SETTINGS)

SELECT c.id, c.name, sum(o.total)

FROM customers c

JOIN orders o ON o.customer_id = c.id

WHERE o.created_at >= now() - interval '7 days'

GROUP BY c.id, c.name

ORDER BY 3 DESC

LIMIT 100;

MySQL は 8.0 でハッシュ JOIN を追加、MariaDB はより早くから対応。ClickHouse 24.x の新オプティマイザ(既定で `enable_analyzer = 1`)は分散 JOIN の書き換えを大幅に改善。

パーティショニングとシャーディング

* **宣言的パーティショニング**: PostgreSQL `PARTITION BY RANGE/LIST/HASH`、MySQL `PARTITION BY` — 単一ノード内。

* **シャーディング**: Vitess(MySQL)、Citus(PG)、TiDB/TiKV、CockroachDB レンジ、Yugabyte tablet。

* **自動分割**: Cockroach・Yugabyte は 64MB(既定)単位で自動分割/併合。

-- PostgreSQL pg_partman で時系列の自動パーティショニング

CREATE TABLE events (

id bigserial,

occurred_at timestamptz NOT NULL,

payload jsonb NOT NULL

) PARTITION BY RANGE (occurred_at);

SELECT partman.create_parent(

p_parent_table => 'public.events',

p_control => 'occurred_at',

p_type => 'native',

p_interval => 'daily',

p_premake => 7

);

-- pg_cron で毎日新パーティション + 60 日前を分離

SELECT cron.schedule('events-maint', '0 2 * * *',

$$CALL partman.run_maintenance_proc()$$);

分散トランザクション — 2PC、Calvin、Raft、Spanner

* **2PC(二相コミット)**: 古典。コーディネーター障害時にブロック。

* **Paxos / Multi-Paxos**: 理論は正しいが実装は地獄。

* **Raft**: etcd、CockroachDB、TiKV、YugabyteDB、FoundationDB(変種)の標準。リーダー選出が明示的で運用しやすい。

* **Calvin**: 決定論的トランザクション順序付け。FaunaDB が採用したが Fauna は 2025 年に終了。

* **Spanner TrueTime**: GPS + 原子時計でクロック不確実性境界 ε を保証。CockroachDB は HLC + uncertainty interval で近似。

Postgres が API を制した理由

1. **拡張性**: extension インターフェースがほぼすべてのワークロードを吸収。`pgvector`(ベクトル)、`timescaledb`(時系列)、`citus`(分散)、`postgis`(地理)、`pg_cron`(スケジューラ)、`pgmq`(キュー)、`pgaudit`(監査)、`pglogical`(論理レプリケーション)、`pg_partman`(パーティショニング)、`hypopg`(仮想インデックス)。

2. **JSONB**: NoSQL を事実上吸収。

3. **MERGE/RETURNING の洗練**: 17 で MERGE に `RETURNING` が入り、18 では `WHEN NOT MATCHED BY SOURCE` まで。

4. **論理レプリケーション v2**: 双方向、並列、シーケンス同期。

5. **AIO(非同期 I/O)**: 18 RC に io_uring/libaio バックエンド。

6. **ブロック増分バックアップ**: 17 の `pg_combinebackup`。

-- Postgres 17/18 MERGE — UPSERT の標準表現

MERGE INTO inventory AS t

USING (

SELECT sku, qty FROM staging.new_stock

) AS s

ON t.sku = s.sku

WHEN MATCHED AND s.qty = 0 THEN DELETE

WHEN MATCHED THEN UPDATE SET qty = t.qty + s.qty, updated_at = now()

WHEN NOT MATCHED THEN INSERT (sku, qty, created_at) VALUES (s.sku, s.qty, now())

WHEN NOT MATCHED BY SOURCE AND t.updated_at < now() - interval '90 days' THEN DELETE

RETURNING merge_action(), t.sku, t.qty;

MySQL 9 / MariaDB 12

Oracle MySQL 9 はベクトルデータ型(2024 年 GA)、JS ストアドファンクション(開発者プレビュー)、そして HeatWave Lakehouse を引き連れた。MariaDB 12 は Oracle MySQL との分岐をさらに加速 — Galera Cluster 4、ColumnStore 統合、JSON Path 強化。

新規採用は鈍化しているが、トス(Toss)・ウアハン兄弟・楽天のような韓国・日本ビッグテックは依然 MySQL を中心 OLTP として運用する。Vitess(クーパン、LINE が一部使用)は PlanetScale から分離され、CNCF 卒業プロジェクトとして定着。

サーバーレス Postgres の経済学

サーバーレス Postgres の本質は二つ。

1. **コンピュートとストレージの分離**: Neon の Pageserver/Safekeeper/Compute の 3 層、Aurora の grain 共有ストレージ、AlloyDB の columnar accelerator。

2. **scale-to-zero**: トラフィック 0 ならコンピュート停止、コスト 0(ストレージのみ請求)。Neon、Supabase Branches、Xata、Cloudflare Hyperdrive がすべてこのモデル。

コールドスタートのコスト: Neon は約 300〜700ms、Supabase プーラーは常時オン、PlanetScale Postgres も常時オン。利用パターンが burst-heavy/dev に近いほど Neon、steady-state に近いほど Supabase または RDS が有利。

Neon Branch + Vercel Preview パターン(概念)

neon:

project: my-app

default_branch: main

preview_strategy:

on_pr_open: create_branch_from_main

branch_name: pr-${PR_NUMBER}

compute_endpoint:

autoscaling: { min_cu: 0.25, max_cu: 4 }

suspend_timeout: 300

protections:

main:

allowed_writers: [migrations-bot, app-prod]

enable_logical_replication: true

ClickHouse — クラウド OLAP の事実上の標準

ClickHouse は MergeTree エンジンファミリーを中心とした列指向ストア。要点:

* **MergeTree**: ソートキーに基づく不変パーツ。バックグラウンドマージでソート・圧縮を維持。

* **ReplicatedMergeTree**: ZooKeeper/ClickHouse Keeper でメタデータ同期。

* **Distributed**: シャーディングルーター。

* **Materialized View**: 挿入時点での事前集計。

-- ClickHouse 時系列 + 分散 + MV パターン

CREATE TABLE events_local ON CLUSTER prod (

ts DateTime CODEC(DoubleDelta, ZSTD(3)),

user_id UInt64,

event LowCardinality(String),

props Map(String, String),

amount Decimal(18, 4) CODEC(Gorilla, ZSTD(3))

) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/events', '{replica}')

PARTITION BY toYYYYMM(ts)

ORDER BY (user_id, event, ts)

TTL ts + INTERVAL 90 DAY DELETE,

ts + INTERVAL 7 DAY TO VOLUME 'cold'

SETTINGS index_granularity = 8192;

CREATE TABLE events ON CLUSTER prod

AS events_local

ENGINE = Distributed('prod', 'default', 'events_local', rand());

CREATE MATERIALIZED VIEW events_daily_mv ON CLUSTER prod

ENGINE = SummingMergeTree

ORDER BY (event, day)

AS SELECT

event,

toDate(ts) AS day,

count() AS cnt,

sum(amount) AS revenue

FROM events_local

GROUP BY event, day;

ClickHouse Cloud はコンピュート・ストレージ完全分離、マルチリージョン複製、autoscaling を提供。韓国のトスが自社分析パイプラインで、日本の LINE がメッセージ分析で ClickHouse を採用しているのが公開されている。

DuckDB — 組み込み Snowflake

DuckDB は SQLite の OLAP 版と呼ばれる。単一バイナリ、組み込み、Parquet/CSV/JSON/Arrow を外部テーブルとして即時スキャン、ベクトル化実行、マルチスレッド。

DuckDB で S3 Iceberg/Parquet 上を即時分析

duckdb << 'SQL'

INSTALL httpfs; LOAD httpfs;

INSTALL iceberg; LOAD iceberg;

SET s3_region='ap-northeast-1';

SET s3_access_key_id='AKIA...';

SET s3_secret_access_key='...';

CREATE VIEW events AS

SELECT * FROM iceberg_scan('s3://lake/warehouse/events');

SELECT

date_trunc('day', ts) AS day,

event,

count(*) AS cnt

FROM events

WHERE ts >= current_date - INTERVAL 30 DAY

GROUP BY 1, 2

ORDER BY 1 DESC, cnt DESC

LIMIT 50;

SQL

DuckDB 1.x で安定性保証を獲得し、MotherDuck(マネージドクラウド)、DuckDB-Wasm(ブラウザ)、DuckDB on Lambda/Workers のような派生が増えた。

StarRocks・Apache Doris・Druid・Pinot

* **StarRocks**: リアルタイム OLAP、MPP、MySQL 互換。外部カタログ(Iceberg/Hudi/Delta)を直接クエリ。韓国カカオ、日本メルカリが一部採用。

* **Apache Doris**: StarRocks と同じ根から分岐。中国発の素早い採用。

* **Apache Druid**: 時系列・リアルタイムインデキシング。Imply が商用ディストリビューション。

* **Apache Pinot**: LinkedIn 発。超低遅延リアルタイム OLAP。UberEats、LinkedIn フィード。

* **Apache Kudu**: 事実上レガシー。Impala とともに停滞状態。

Druid vs Pinot vs ClickHouse の選択ガイド

* **ミリ秒遅延 + リアルタイムインデキシングが絶対優先**: Druid または Pinot。

* **PB 級 OLAP、豊富な SQL、マテリアライズドビュー**: ClickHouse。

* **Iceberg/Hudi 上のフェデレーション、MySQL 互換**: StarRocks/Doris。

* **ノート PC・Lambda・エッジ**: DuckDB。

NewSQL — TiDB、CockroachDB、YugabyteDB、Spanner

分散 SQL は「水平スケール可能な ACID OLTP」を目指す。

* **TiDB**: MySQL 互換。TiKV(Raft)+ PD(メタ)+ TiDB(SQL レイヤ)。HTAP のため TiFlash(列)を同梱。

* **CockroachDB 25**: PostgreSQL ワイヤー互換。レンジベース分散、follower reads、マルチリージョントポロジー。

* **YugabyteDB**: PG/Cassandra 互換のデュアルインターフェース。xCluster で非同期マルチリージョン。

* **Spanner**: TrueTime。GCP でのみマネージド、オンプレ GA(2025)。

* **Aurora DSQL**: AWS の分散 Postgres。multi-active multi-region。

-- TiDB EXPLAIN ANALYZE — coprocessor pushdown を確認

EXPLAIN ANALYZE

SELECT user_id, sum(amount)

FROM orders

WHERE created_at >= '2026-05-01'

GROUP BY user_id

HAVING sum(amount) > 1000;

Cassandra 5・ScyllaDB・Aerospike

リーダーレス wide-column ストアたち。

* **Cassandra 5**: Storage-attached indexes(SAI)、トライベース memtable、ベクトル検索。クーパンが商品カタログ/注文メタで運用。

* **ScyllaDB**: C++ 再実装、seastar shard-per-core。Cassandra ワイヤー互換。少ないノードで同じスループット。

* **Aerospike**: メモリ + SSD ハイブリッド。日本の楽天の広告/レコメンドシステムが代表事例。

-- Cassandra CQL: TTL + LWT

CREATE TABLE sessions (

user_id uuid,

session_id timeuuid,

ip inet,

payload text,

PRIMARY KEY (user_id, session_id)

) WITH default_time_to_live = 86400

AND compaction = { 'class' : 'TimeWindowCompactionStrategy', 'compaction_window_size' : 1, 'compaction_window_unit' : 'HOURS' };

INSERT INTO sessions (user_id, session_id, ip, payload)

VALUES (uuid(), now(), '203.0.113.1', '{"agent":"chrome"}')

IF NOT EXISTS;

SQLite・libSQL・Turso・rqlite・Cloudflare D1

組み込み SQL は「どこでも動く DB」が核心。

* **SQLite**: 世界で最も多くデプロイされた DB。WAL、FTS5、JSON1、rtree。

* **libSQL**: Turso が作った SQLite fork。マルチライター、組み込み replica。

* **Turso**: libSQL マネージド。エッジ分散。

* **rqlite**: SQLite + Raft 分散。

* **Cloudflare D1**: SQLite ベース。Workers と統合。

* **LiteFS**: Fly.io の SQLite レプリケーション FS(やや停滞)。

Embedded → Edge の流れ

サーバーレス v2 のキーワードは「エッジデータベース」。ユーザーに近い PoP にデータを置き、整合性は緩く保つ。Turso の組み込み replica、Cloudflare D1、PlanetScale Boost、Vercel Edge Config はすべて同じ流れ。

Mongo・DynamoDB・Cosmos DB

* **MongoDB 8**: queryable encryption、time-series コレクション、ベクトル検索。ACID マルチドキュメントトランザクション。

* **DynamoDB**: AWS 専用。PK/SK 設計がすべて。global tables。

* **Cosmos DB**: Mongo・Cassandra・Gremlin・SQL API。Azure 専用。

Neon・Supabase・PlanetScale・Xata・Convex

* **Neon**: 最も純粋な Postgres サーバーレス。branching、scale-to-zero、autoscaling。

* **Supabase**: Postgres + Auth + Storage + Edge Functions + Realtime。フルスタック BaaS。

* **PlanetScale**: 2024 年に Vitess → Postgres にピボット。Boost 自動キャッシュ。

* **Xata**: Postgres 上に検索・ファイル・BFF。

* **Convex**: TS ネイティブ reactive DB。SQL ライク + 関数型 mutation。

Fauna は 2025 年に終了、データは Convex/Neon への移行ガイドが提供されている。

EdgeDB → Gel、SurrealDB

* **EdgeDB** が **Gel** にリブランド(2025 年末)。独自 EdgeQL、Postgres 上に立つ graph-relational。マイグレーションツールが強み。

* **SurrealDB**: マルチモデル(document + graph + KV + relational)。ライブクエリ。

新規採用は遅いが、AI エージェントがスキーマを扱いやすい抽象として再評価中。

Postgres 拡張 — 運用必須 7 種

| 拡張 | 用途 |

| --- | --- |

| pg_stat_statements | クエリ統計 |

| pg_repack | オンライン VACUUM FULL 代替 |

| pgvector | ベクトル検索 |

| timescaledb | 時系列ハイパーテーブル |

| citus | 分散シャーディング |

| pg_partman | パーティション自動化 |

| pg_cron | DB 内スケジューラ |

加えて `pgaudit`(監査)、`hypopg`(仮想インデックス)、`pg_stat_kcache`、`auto_explain`、`pgbouncer`(外付け)。

コネクションプーリング — PgBouncer、Pgpool-II、ProxySQL、Vitess

pgbouncer.ini — トランザクションプーリング + 認証委譲

[databases]

app = host=primary.internal port=5432 dbname=app

[pgbouncer]

listen_port = 6432

pool_mode = transaction

default_pool_size = 50

reserve_pool_size = 10

reserve_pool_timeout = 5

max_client_conn = 5000

server_idle_timeout = 600

auth_type = scram-sha-256

auth_user = pgb_auth

auth_query = SELECT u.usename, u.passwd FROM pg_shadow u WHERE u.usename = $1

ignore_startup_parameters = extra_float_digits

admin_users = pgb_admin

PostgreSQL 18 はネイティブ接続プーラーの作業が進行中(まだ GA ではない)。Supavisor(Supabase)、Hyperdrive(Cloudflare)、AlloyDB プーラーがクラウドプーラーの代表格。

DB 可観測性 — pganalyze、Datadog DBM、OtterTune、EverSQL

* **pganalyze**: Postgres 特化。log + pg_stat_statements を融合し自動インデックス推奨。

* **Datadog DBM**: Postgres/MySQL/Mongo/SQL Server マルチ。APM 連携。

* **OtterTune**: ML ベースの自動チューニング(現在サービス縮小)。

* **EverSQL**: MySQL クエリ最適化 SaaS。

* **PMM(Percona)**、**PoWA**、**mongostat/mongotop**、**ClickHouse system.query_log** など OSS の選択肢も豊富。

ORM 地形図 2026

| 言語 | 1 ティア | 上昇中 | 備考 |

| --- | --- | --- | --- |

Prisma Postgres は 2024 年に発表 — Prisma が独自マネージド Postgres を提供開始。Drizzle Studio はローカル GUI で zero-config が魅力。

韓国・日本の運用事例

* **トス(Toss)**: 多数の Aurora MySQL クラスタ + ClickHouse 分析。自社 DB on-call 文化が有名。

* **クーパン**: Cassandra の大規模運用(商品/注文メタデータ)。DynamoDB も一部。

* **カカオ**: MySQL + 自社 Cubrid レガシー一部 + ClickHouse。

* **ネイバー**: Cubrid(自社 RDBMS)レガシー + Postgres/MySQL + HBase。

* **LINE**: PostgreSQL 大規模、MongoDB、Vitess、一部 ClickHouse。

* **メルカリ**: 大規模 OLTP に Cloud Spanner を採用 — 代表事例が多数公開。

* **楽天(Rakuten)**: Aerospike(広告/レコメンド)、Cassandra、Postgres。

比較表 — 一枚要約

| エンジン | モデル | 一貫性 | 分散 | ライセンス |

| --- | --- | --- | --- | --- |

| DuckDB | column | n/a | n/a | MIT |

データレイク上の SQL — Iceberg + DuckDB + ClickHouse

2026 年最大の流行: **データウェアハウスはコンピュートに過ぎず、真実は Iceberg テーブルにある。**

Terraform: AWS Glue Iceberg + S3 + Athena/ClickHouse/DuckDB が同じテーブルを照会

resource "aws_s3_bucket" "lake" {

bucket = "yj-blog-lake-prod"

}

resource "aws_glue_catalog_database" "warehouse" {

name = "warehouse"

}

resource "aws_glue_catalog_table" "events" {

database_name = aws_glue_catalog_database.warehouse.name

name = "events"

table_type = "EXTERNAL_TABLE"

parameters = {

"table_type" = "ICEBERG"

"format" = "iceberg/parquet"

"metadata_location" = "s3://yj-blog-lake-prod/warehouse/events/metadata/v1.metadata.json"

}

storage_descriptor {

location = "s3://yj-blog-lake-prod/warehouse/events/"

columns {

name = "ts"

type = "timestamp"

}

columns {

name = "user_id"

type = "bigint"

}

columns {

name = "event"

type = "string"

}

ClickHouse は `iceberg`/`deltalake` テーブル関数、DuckDB は `iceberg_scan`、Snowflake は external iceberg table、BigQuery は BigLake — すべて同じデータを見ている。

データモデリング — 正規化は終わったか

答え: **OLTP では依然 3NF に近く**、OLAP では **スタースキーマまたは wide table**。JSONB/Map は明確な用途(可変属性、ユーザー定義フィールド)にだけ使い、PK・外部キー・インデックスで制御できる領域はカラムにフラット化する。

マイグレーションとスキーマ進化

* **Atlas(Ent)**: 宣言的マイグレーション。GitOps 親和。

* **sqitch / Flyway / Liquibase**: 古典。

* **Drizzle Kit / Prisma Migrate**: TS ネイティブ。

* **gh-ost / pt-online-schema-change**: MySQL 無停止スキーマ。

* **pgroll**: Xata 製の Postgres expand/contract マイグレーション。

セキュリティ — RLS、行レベル暗号化、queryable encryption

PostgreSQL の RLS は SaaS マルチテナンシーの武器。

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices

USING (tenant_id = current_setting('app.tenant_id', true)::uuid)

WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- アプリがトランザクション開始時にコンテキスト設定

SET LOCAL app.tenant_id = '11111111-2222-3333-4444-555555555555';

MongoDB 8 の queryable encryption は暗号文で等価比較を可能にする。CockroachDB と YugabyteDB もクライアントサイド暗号化 SDK を提供。

バックアップと PITR

* **pg_basebackup + WAL archiving + pg_combinebackup(PG17+)**: 標準。

* **pgBackRest、Barman、WAL-G**: 運用ツール。

* **Velero + ストレージスナップショット**: K8s 環境。

* **CockroachDB BACKUP/RESTORE**、**Cassandra nodetool snapshot**、**MySQL Percona XtraBackup**。

コストモデル比較

| カテゴリ | 代表 | 価格モデル | 強み |

| --- | --- | --- | --- |

どのエンジンをいつ使うか — 決定木

* OLTP 新規プロジェクト: **Postgres**。

* 分析/ダッシュボード: **ClickHouse** または **DuckDB** + Parquet/Iceberg。

* マルチリージョン強整合: **Spanner** または **CockroachDB**。

* 超高 QPS キーバリュー: **ScyllaDB**、**Aerospike**、**DynamoDB**。

* 検索: **Elasticsearch/OpenSearch** または **Postgres `tsvector` + pgvector**。

* 時系列: **TimescaleDB**(PG ext)、**ClickHouse**、**InfluxDB 3**、**VictoriaMetrics**。

* グラフ: **Neo4j**、**Postgres + AGE**、**TigerGraph**、**SurrealDB**。

* 組み込み/エッジ: **SQLite/libSQL**、**DuckDB**。

結論 — 2026 年のシンプルな推奨

デフォルトは **Postgres**(マネージドなら Neon/Supabase/RDS)、分析が必要なら **DuckDB で始め、ClickHouse に卒業**する。マルチリージョン ACID がビジネス要件なら **CockroachDB または Spanner**。超高 QPS は **Scylla**。組み込みは **SQLite/libSQL**。ORM は TS なら **Drizzle**、Go なら **sqlc**、Python なら **SQLAlchemy 2.x**、Rust なら **sqlx + Diesel/SeaORM**。

データベース選択はもう宗教戦争ではない。ワークロードパターン、チームが運用できる限界、そして最も決定的に — **このデータの中でどの質問に 1 秒以内に答えなければならないか** — がすべてを決める。

References

- [postgresql.org](https://www.postgresql.org/) — PostgreSQL 公式

- [dev.mysql.com](https://dev.mysql.com/) — MySQL 公式

- [mariadb.org](https://mariadb.org/) — MariaDB

- [sqlite.org](https://www.sqlite.org/) — SQLite

- [duckdb.org](https://duckdb.org/) — DuckDB

- [clickhouse.com](https://clickhouse.com/) — ClickHouse

- [starrocks.io](https://www.starrocks.io/) — StarRocks

- [doris.apache.org](https://doris.apache.org/) — Apache Doris

- [druid.apache.org](https://druid.apache.org/) — Apache Druid

- [pinot.apache.org](https://pinot.apache.org/) — Apache Pinot

- [cassandra.apache.org](https://cassandra.apache.org/) — Apache Cassandra

- [scylladb.com](https://www.scylladb.com/) — ScyllaDB

- [tidb.io](https://www.pingcap.com/tidb/) — TiDB

- [cockroachlabs.com](https://www.cockroachlabs.com/) — CockroachDB

- [yugabyte.com](https://www.yugabyte.com/) — YugabyteDB

- [neon.tech](https://neon.tech/) — Neon

- [supabase.com](https://supabase.com/) — Supabase

- [planetscale.com](https://planetscale.com/) — PlanetScale

- [turso.tech](https://turso.tech/) — Turso / libSQL

- [geldata.com](https://www.geldata.com/) — Gel(EdgeDB の後継)

- [surrealdb.com](https://surrealdb.com/) — SurrealDB