データベースエンジン 2026 ディープダイブ — Postgres が API を制し、ClickHouse と DuckDB が分析を制した

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 種

加えて 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

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。

比較表 — 一枚要約

データレイク上の 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 — PostgreSQL 公式
• dev.mysql.com — MySQL 公式
• mariadb.org — MariaDB
• sqlite.org — SQLite
• duckdb.org — DuckDB
• clickhouse.com — ClickHouse
• starrocks.io — StarRocks
• doris.apache.org — Apache Doris
• druid.apache.org — Apache Druid
• pinot.apache.org — Apache Pinot
• cassandra.apache.org — Apache Cassandra
• scylladb.com — ScyllaDB
• tidb.io — TiDB
• cockroachlabs.com — CockroachDB
• yugabyte.com — YugabyteDB
• neon.tech — Neon
• supabase.com — Supabase
• planetscale.com — PlanetScale
• turso.tech — Turso / libSQL
• geldata.com — Gel(EdgeDB の後継)
• surrealdb.com — SurrealDB