ScalarDB Clusterとは｜異種DB横断ACIDの仕組みと3.20の変更点・Kubernetes導入

ScalarDB Clusterは、MySQLとCassandra、PostgreSQLとDynamoDBのように種類の違うデータベースをまたぐ処理を、1つのACIDトランザクションとして実行するミドルウェアです。オープンソースのScalarDB（Community版）をKubernetes上でクラスタ化した商用版で、Enterprise StandardとEnterprise Premiumの2エディションがあります。2026年10月30日公開の3.20では、3.19で非推奨になった2フェーズコミット（2PC）インターフェースがライブラリから消え、マイクロサービス間のトランザクションはTransaction CoordinatorとGlobal Transaction APIに一本化されました。本記事では、3.20のリリースノートとソースコード、公式ドキュメントをもとに、構成、エディション差、3.20へ上げるときに壊れる箇所、Kubernetesへの導入と本番の冗長化構成を整理します。

まとめ：ScalarDB Clusterの要点

• ScalarDB Clusterは、ScalarDBの機能を持つノード群をKubernetes上で動かす構成です。ノード間の振り分けにはコンシステントハッシュを使い、メンバー情報はKubernetes APIから取得します。本番はKubernetes前提で、開発・テスト用にはスタンドアロンモードがあります。
• 下位DBのトランザクション機能には頼らず、Consensus Commitというプロトコルで異種DB間のACIDを実現します。分離レベルの既定はSNAPSHOTで、SERIALIZABLEも選べます。
• Community版（Core）でもDB横断トランザクションは使えます。クラスタリングと認証・認可はEnterprise Standard以上、SQL・JDBC・Spring Data JDBC・GraphQLはEnterprise Premiumに限られます。
• 3.20で2PCインターフェースとjoin()・resume()が削除されました。3.19.2向けの2PCコードは3.20.0のjarに対してコンパイルが通りません。分離クラスタ型の構成は、Transaction CoordinatorとGlobal Transaction APIへ書き換えてから上げます。
• 本番の最小構成は、4vCPU・8GBメモリのワーカーノード3台にScalarDB ClusterのPodを3つ分散させる形です。ゾーン障害まで耐えるには、ノードを別々のアベイラビリティゾーンに置きます。

以下、構成とプロトコル、エディション、接続方式、3.20の変更、導入と本番構成の順に説明します。

ScalarDB Clusterの構成：ScalarDBをクラスタ化したgRPCサーバー

ScalarDBには、ライブラリとしてアプリケーションに組み込むCoreと、サーバーとして動かすClusterがあります。Clusterの各ノードはCoreの機能をすべて持ち、アプリケーションからのリクエストをgRPCで受け付けます。クライアントSDKはJava版と.NET版があり、gRPCのprotoファイルからほかの言語のクライアントも生成できます（protoファイルはサポート窓口から入手します）。

Clusterが必要になる理由は、トランザクションの状態がサーバー側にあることです。複数のリクエストにまたがるトランザクションでは、同じトランザクションのリクエストをすべて同じノードで処理しなければなりません。ロードバランサーのセッションアフィニティで対処すると製品ごとに設定が変わるため、ScalarDB Clusterでは、リクエストを受けたノードがコンシステントハッシュで担当ノードを判定し、自分の担当でなければ正しいノードへ転送します。転送回数の上限は scalar.db.cluster.hop_limit（既定値3）です。ノードの参加と離脱はKubernetes APIで検知し、構成が自動で組み直されます。

5432番は scalar.db.postgres.port の既定値で、scalar.db.postgres.enabled=true にしたときだけ開きます。Transaction Coordinatorを使う構成では、Coordinator側の60055番（クライアントの contact_port 既定値）も加わります。

Consensus Commitの仕組みと分離レベル

ScalarDBのトランザクションは、XAのように下位DBのトランザクション機能を使うのではなく、ScalarDB自身が実装するConsensus Commitプロトコルで処理されます。並行制御は楽観的並行性制御（OCC）で、コミットは次の順で進みます。

1. 準備（prepare）：書き込むレコードを「準備済み」の状態で各DBへ書く。ほかのトランザクションと競合していれば、Coordinatorテーブルに ABORTED を書いて中断する。
2. 検証（validate）：分離レベルがSERIALIZABLEのときだけ、読んだレコードを読み直し、書き換えられていないかを確かめる。
3. コミット状態の確定：Coordinatorテーブルにトランザクションごとの COMMITTED レコードを書く。この書き込みが成功した時点でコミット済みになる。
4. レコードの確定：準備済みのレコードを COMMITTED に書き換え、ほかのトランザクションから見えるようにする。

競合の検出には、各DBが備える条件付き書き込みを線形化可能な形で使います。トランザクションのメタデータはアプリケーションのデータと同じテーブルに持つのが既定で、これが分散した先行書き込みログ（WAL）の役割を果たします。障害時にはCoordinatorテーブルの状態を見て、途中のトランザクションをロールバックまたはロールフォワードで復旧します。3.20では、連続するGet操作を並列にまとめて読む設定（scalar.db.consensus_commit.parallel_batch_get.enabled）が加わり、ロールバック対象のレコードも並列に読むようになりました。

既定のSNAPSHOTは、ドキュメント上は「読み取りコミット・スナップショット分離（スナップショット分離の弱い変種）」と説明されています。残高チェックのように、読んだ値を条件に別のレコードを更新する処理ではライトスキューが起きうるため、SERIALIZABLEを選びます。プロトコルの正しさは、GitHubの tla+/consensus-commit にあるTLA+の形式仕様と、scalar-labs/scalar-jepsen の障害注入テストで検証されています。

対応データベースとエディション別の機能

3.20で使える下位データベース

ClusterはCoreを通じてデータベースにアクセスするため、対応DBはCoreと同じです。2026年10月31日時点の公式ScalarDB Requirementsは3.19までの表で、そこに3.20.0のリリースノートの変更（SQL Server 2025の追加と2017の削除。同日公開の3.19.2にも同じ変更が入っています）を反映すると次のとおりです。

Db2はLinux・UNIX・Windows版のみで、z/OS版には対応していません。組み合わせるDBのどれか1つにCoordinatorテーブルを置きます。3.19.1からは、Aurora PostgreSQLとAurora MySQLの高速フェイルオーバーのためにAWS Advanced JDBC Wrapperにも対応しています。Cassandraのデータモデル自体はCassandraの仕組みとデータモデルで解説しています。

Community・Enterprise Standard・Enterprise Premiumの機能差

判断を分けるのはSQLが必要かどうかです。既存のJavaアプリケーションをJDBCやSpring Data JDBC経由で動かしたいならPremiumが前提になります。CRUD APIで実装でき、暗号化などPremium限定の機能が要らないならStandardで足ります。属性ベースのアクセス制御（Public Preview）は別途のオプション契約です。CoreはApache License 2.0で公開されています。

クライアントの接続方式：direct-kubernetes・indirect・PostgreSQLワイヤプロトコル

Javaクライアントのdirect-kubernetesとindirect

Javaのクライアントライブラリには、direct-kubernetesとindirectの2つの接続モードがあります。公式の本番チェックリストは、性能面からdirect-kubernetesを推奨しています。

• direct-kubernetes：アプリケーションのPodをScalarDB Clusterと同じKubernetesクラスタに置き、クライアントがメンバー情報を読んで担当ノードへ直接つなぐ。Envoyは不要だが、エンドポイントを読むためのRole・RoleBinding・ServiceAccountを用意する。
• indirect：クラスタの外のアプリケーションから、Envoyのロードバランサー経由でつなぐ。Java以外の言語でgRPC APIを直接使う場合もEnvoyが必要になる。

# direct-kubernetes モード（名前空間 ns のエンドポイント scalardb-cluster を参照）
scalar.db.transaction_manager=cluster
scalar.db.contact_points=direct-kubernetes:ns/scalardb-cluster
# indirect モード（Envoy のロードバランサーの IP アドレスを指定）
# scalar.db.contact_points=indirect:192.168.10.1

本番では、CRUD APIなら scalar.db.transaction_manager=cluster、SQL APIなら scalar.db.sql.connection_mode=cluster になっているかを確認します。3.20では内部用だった singleton: の接続先指定（SINGLETONモード）が削除されました。また、direct-kubernetesのクライアントを閉じてもスレッドとKubernetes APIサーバーへの接続が残る不具合が、3.19.2と3.20で直っています。クライアントを作っては閉じる処理（JDBCドライバー経由を含む）で、いずれ新しいスレッドを作れなくなる症状が出ていたなら、このどちらかへ上げます。

PostgreSQLワイヤプロトコルでの接続（3.20）

3.20から、ScalarDB ClusterのノードがPostgreSQLのワイヤプロトコルを話せるようになりました。psql、PostgreSQL JDBCドライバー、そのほかのPostgreSQL用ツールから、ScalarDB Clusterに対してSQLを実行できます。ScalarDB専用のJDBCドライバーやSDKを入れられないツール（BIツールや運用スクリプト）を接続したい場面で効きます。

# ScalarDB Cluster ノードのプロパティ
scalar.db.postgres.enabled=true
scalar.db.postgres.port=5432
# userpass（パスワードのみ）か oidc_jwt（OIDCアクセストークンのみ）に絞れる
scalar.db.postgres.auth=userpass

認証を有効にしたクラスタでは、クライアントはScalarDB Clusterのユーザーとしてログインし、パスワードかOIDCアクセストークン（パスワード欄に入れる）を使います。権限はほかのクライアントと同じく検査され、接続には既定でTLSが必須です。証明書を個別に指定しなければ、ノードのTLS証明書と秘密鍵が使われます。対応しないSQL構文やPostgreSQL固有機能の一覧は、2026年10月31日時点の公式ドキュメントでは確認できませんでした。既存のPostgreSQL向けクエリをそのまま流す前に、検証環境で通るかを確かめてください。

3.20で変わった点とアップグレードの確認項目

2PCインターフェースの削除とGlobal Transaction APIへの一本化

マイクロサービスでScalarDB Clusterを使う構成には、すべてのサービスが1つのClusterを共有する共有クラスタ型と、サービスごとにClusterを持つ分離クラスタ型があります。分離クラスタ型では、各サービスが prepare を呼び、全員の成功を確かめてから commit する2PCインターフェースをアプリケーションで実装していました。

このインターフェースは3.19で非推奨になり、3.20で消えました。3.20.0のリリースノートは概要で「レガシーなトランザクションAPIの削除」とまとめ、個別項目にはjoin()・resume()やGraphQLの2PC（@twoPhaseCommit ディレクティブと prepare・validate・commit のミューテーション）の削除が並びます。2PCインターフェース本体の削除は個別項目に書かれていませんが、Maven Centralの3.20.0のjarには TwoPhaseCommitTransactionManager と TransactionFactory.getTwoPhaseCommitTransactionManager() がありません。2026年10月31日に、このメソッドを呼ぶだけのコードをコンパイルしたところ、3.19.2のjarでは非推奨の注意だけで通り、3.20.0のjarでは「cannot find symbol」の3件のエラーで止まりました。Cluster Java Client SDKの3.20.0からも、ClusterClientTwoPhaseCommitTransactionManager と ClusterClientSqlTwoPhaseCommitTransactionManager が消えています。

これから設計する場合は、まず共有クラスタ型で要件を満たせるかを確かめます。公式ドキュメントはもともと「可能な限り共有クラスタ型を使う」としており、Clusterは重要な状態をメモリに持たないため、共有してもサービスごとのDB分割の原則から大きくは外れません。クラスタを分ける必要があるときは、次のTransaction Coordinatorを使います。

Transaction CoordinatorとGlobal Transaction APIの実装

Transaction Coordinator（3.19.0で追加）は独立したプロセスとして動き、アプリケーションに代わって複数のClusterに対する2PCを進めます。アプリケーション側は GlobalTransactionManager を使います。起点のサービスが begin() でグローバルトランザクションを開始してIDをほかのサービスへ渡し、各サービスはそのIDで beginBranch() を呼んで担当分のCRUDを実行し、end(Status) で結果を宣言します。起点のサービスは、すべてのブランチが SUCCESS で終わったことを確かめてから commit() を呼びます。

次のコードは、注文サービスが決済サービスを呼び出してコミットするまでの抜粋です（import、メソッド宣言、orderId・customerId・amount・customerの定義は省略）。BranchTransaction.java（v3.20.0）のJavadocが示す形に合わせており、scalardb 3.20.0のjarに対してコンパイルが通ることを確認しています（クラスタ上での実行はしていません）。

TransactionFactory factory = TransactionFactory.create("scalardb-client.properties");
GlobalTransactionManager manager = factory.getGlobalTransactionManager();

GlobalTransaction global = manager.begin();
BranchTransaction branch = null;
try {
  branch = manager.beginBranch(global.getId());
  branch.insert(Insert.newBuilder()
      .namespace("order_service").table("orders")
      .partitionKey(Key.ofText("order_id", orderId))
      .intValue("amount", amount)
      .build());
  branch.end(BranchTransaction.Status.SUCCESS);
  // 決済サービスは同じIDで beginBranch し、処理後に end(SUCCESS) してから応答する
  customer.pay(global.getId(), customerId, amount);
  global.commit();
  // managerはアプリケーション終了時に manager.close() で閉じる
} catch (Exception e) {
  // 3.20では、SUCCESS宣言後のFAILURE宣言とcommit後のrollbackは何もしない
  if (branch != null) {
    try {
      branch.end(BranchTransaction.Status.FAILURE);
    } catch (RuntimeException | CrudException suppressed) {
      e.addSuppressed(suppressed);
    }
  }
  try {
    global.rollback();
  } catch (RollbackException suppressed) {
    e.addSuppressed(suppressed);
  }
  // UnknownTransactionStatusExceptionなら結果は未確定。結果を確かめるまで再試行しない
  throw e;
}

3.20では、commit() が成功しても失敗してもトランザクションはそこで終わり、その後の rollback() は何もしません。そのため、失敗時の後始末を1つの catch にまとめられます。注意点は、GlobalTransaction.java（v3.20.0）のJavadocにあるとおり「すべてのブランチが SUCCESS で終わるまで commit() しない」を強制する仕組みが無いことです。処理中のブランチがあるままコミットすると、その途中までの書き込みがコミットされる可能性があります。

クライアント側では、Transaction Coordinatorへトランザクション制御を送る設定を有効にします。

scalar.db.transaction_manager=cluster
scalar.db.contact_points=indirect:order-cluster
scalar.db.cluster.id=order-cluster
scalar.db.cluster.client.transaction_coordinator.enabled=true
scalar.db.cluster.client.transaction_coordinator.contact_points=indirect:transaction-coordinator

参加する側のClusterノードでは scalar.db.cluster.node.transaction_participant.enabled=true と scalar.db.cluster.id を、Transaction Coordinator側では対象のClusterを scalar.db.cluster.transaction_coordinator.clusters に列挙します。transaction_coordinator.enabled を false に戻すと、同じアプリケーションコードが1つのCluster内のトランザクションとして動くので、共有クラスタ型と分離クラスタ型を設定だけで切り替えられます。

SQLのグローバルトランザクション（GLOBAL_TRANSACTIONモード）

3.19のGlobal Transaction APIはCRUD API向けでしたが、3.20でScalarDB SQLにも同じ仕組みが入りました。SqlSession とJDBCドライバーに GLOBAL_TRANSACTION モードが加わり、あるプロセスが開始したグローバルトランザクションに対して、各プロセスが BEGIN BRANCH と END BRANCH でブランチを実行します。Transaction Coordinator側で scalar.db.sql.enabled=true にすると、CoordinatorがSQLのトランザクションについても複数Clusterの2PCを進めます。CRUD APIと同じく、同じアプリケーションコードが設定次第で1つのCluster内のトランザクションとしても動きます。SQLの構文の詳細（ブランチの終了状態の書き方など）は、2026年10月31日時点の公式ドキュメントでは確認できず、本記事ではリリースノートの説明までにとどめます。

3.19から3.20へ上げる前の確認項目

リリースノートとjarの差分から、アップグレードで動作やビルドが変わる箇所を抜き出すと次のとおりです。SQL Server 2017の削除とJava 21化は3.19.2にも入っているため、3.19.0・3.19.1から上げる場合に関係します。

設定名は、scalar.db.active_transaction_management.enabled が scalar.db.two_phase_commit.active_transaction_management.enabled になり、2PCのコーディネーターと参加者にだけ効くようになりました。scalar.db.active_transaction_management.expiration_time_millis の既定値は -1 から 60000 に変わりました。長い時間開いたままにするトランザクションがある処理は、上げる前にこの値を明示しておきます。Spring Data連携の ScalarDbRepositoryImpl から begin()・commit()・rollback() などが外れた点と、BranchTransaction.getId() がブランチ自身のIDを返すようになった点（グローバルトランザクションのIDは getGlobalTransactionId()）も、コンパイルや動作に影響します。

KubernetesへのHelm導入手順

公式のHelm Chartは scalar-labs/scalardb-cluster です。2026年10月30日公開のChart 1.13.0がScalarDB 3.20.0に対応しています（appVersion 3.20.0）。ローカルのKubernetesで試す流れは次のとおりです。

1. 下位DB（例：PostgreSQL）をHelmで起動する。
2. helm repo add scalar-labs https://scalar-labs.github.io/helm-charts でリポジトリを登録する。
3. DBの認証情報とライセンスキーを kubectl create secret generic でSecretに入れる。
4. カスタム値ファイルを保存し、helm install scalardb-cluster scalar-labs/scalardb-cluster -f scalardb-cluster-custom-values.yaml --version 1.13.0 -n default を実行する。
5. kubectl get pod でノードとEnvoyのPodがそれぞれ3つずつ Running になったことを確かめ、kubectl get svc でEnvoyの外部IPを確認する。

カスタム値ファイルの中心はノードのプロパティです。公式チュートリアルの値ファイルから、ストレージとライセンスの設定を抜き出すと次のようになります。

envoy:
  enabled: true
  service:
    type: "LoadBalancer"
scalardbCluster:
  image:
    repository: "ghcr.io/scalar-labs/scalardb-cluster-node-byol-premium"
  scalardbClusterNodeProperties: |
    scalar.db.cluster.membership.type=KUBERNETES
    scalar.db.cluster.membership.kubernetes.endpoint.namespace_name=${env:SCALAR_DB_CLUSTER_MEMBERSHIP_KUBERNETES_ENDPOINT_NAMESPACE_NAME}
    scalar.db.cluster.membership.kubernetes.endpoint.name=${env:SCALAR_DB_CLUSTER_MEMBERSHIP_KUBERNETES_ENDPOINT_NAME}
    scalar.db.storage=jdbc
    scalar.db.contact_points=jdbc:postgresql://postgresql-scalardb-cluster.default.svc.cluster.local:5432/postgres
    scalar.db.username=${env:SCALAR_DB_CLUSTER_POSTGRES_USERNAME}
    scalar.db.password=${env:SCALAR_DB_CLUSTER_POSTGRES_PASSWORD}
    scalar.db.cluster.node.licensing.license_key=${env:SCALAR_DB_CLUSTER_LICENSE_KEY}
    scalar.db.cluster.node.licensing.license_check_cert_pem=${env:SCALAR_DB_CLUSTER_LICENSE_CHECK_CERT_PEM}
  secretName: "scalardb-credentials-secret"

イメージ名の byol-premium は、ライセンスキーを自分で持ち込むPremium版を表します。アプリケーションをdirect-kubernetesモードで動かす場合は、クライアントのServiceAccountにエンドポイントの get・watch・list を許可するRoleを割り当てます。Kubernetesのリソースとエンドポイントの関係はKubernetes APIの仕組みとリソース構造で解説しています。

本番構成の冗長化・リソース・費用

冗長化の構成：Pod・ノード・ゾーンの3段

ScalarDB Clusterの冗長化は、どの単位の障害に耐えるかで3段に分かれます。公式の本番チェックリストの最小構成は、ワーカーノード3台以上にScalarDB ClusterのPodを3つ以上分散させる形です。

• Pod単位：Podを3つ以上動かす。障害後はメンバー情報の更新で残りのノードへ振り分けられる。ただし、処理中のトランザクションがそのまま継続する保証はなく、エラーに応じた再試行やコミット結果の確認が必要になる。
• ノード単位：podAntiAffinity で同じワーカーノードにPodが偏らないようにする。
• ゾーン単位：ワーカーノードを別々のアベイラビリティゾーンに置き、ゾーン障害でもPodが残るようにする。

Clusterのノードは重要な状態を永続化しないため、データの冗長化は下位DB側の責任です。下位DBでは自動バックアップとポイントインタイムリカバリ（PITR）を有効にします。ClusterはScalar Adminのインターフェースを実装しており、一時停止してトランザクション整合性のあるバックアップを取れます。Clusterはインターネットに直接サービスを出さないため、プライベートネットワークに置きます。

ノードのサイズとPAYGのリソース上限

BYOLコンテナのPodには2vCPU・4GBメモリ以上を割り当てます。同じノードにEnvoy・アプリケーション・監視のPodも載るため、ワーカーノードは4vCPU・8GBメモリ以上を3台が最小です。HPAでPodを自動で増やす場合は、上限のPod数からノードの大きさを逆算します。

2vCPU・4GBの扱いは、ライセンスの持ち込み方で変わります。BYOLでは推奨値ですが、AWS Marketplaceの従量課金（PAYG）コンテナでは resources.limits の上限で、これを超える値を設定したPodは自動で停止します。PAYGで処理能力を上げるには、Podを大きくせずPodの数を増やします。

scalardbCluster:
  resources:
    requests:
      cpu: 2000m
      memory: 4Gi
    limits:
      cpu: 2000m
      memory: 4Gi

ScalarDB ClusterのPAYG料金とバージョン別保守期限

AWS MarketplaceのEnterprise Standard（従量課金）とEnterprise Premium（従量課金）のリスティングでは、2026年10月31日時点でStandardが1ユニットあたり1.40ドル、Premiumが2.79ドルです。Scalarの料金ページはこれを1時間あたりの価格として表示しています。同じページの注記では、2vCPU・4GBメモリのPod 1つを1ユニットと数えます。最小構成のPod 3つなら、ライセンス分だけでStandardが1時間4.20ドル、Premiumが8.37ドルです。Google Cloudでの価格はStandardが1時間1.50ドル、Premiumが2.89ドルと表示されています。インフラ費用は別にかかり、BYOLの価格は販売元への問い合わせになります。既存のRDBとNoSQLをどう組み合わせて載せるかの設計から相談したい場合は、データベース設計・移行支援で対応しています。

保守期限は公式のリリースサポートポリシーで確認します。2026年10月31日時点の表では、3.20は「TBD」（次のマイナーバージョンが出たときに確定）、3.18はメンテナンスサポートが2027年8月2日まで、3.17は2027年5月1日まで、3.16は2026年11月26日までです。3.19のメンテナンスサポート終了日は2026年10月30日、アシスタンスサポート終了日は2027年4月28日と書かれています。3.19だけが前の版より早く終わる表記になっているため、3.19で運用中なら保守の残り期間を契約窓口で確認したうえで、3.20への移行計画を立ててください。

ScalarDB Clusterを採用すべきでないケース

ScalarDB Clusterは、異種DBをまたぐ強い整合性が必須の場面で効く製品です。次の条件に当てはまるなら、別の手段を先に検討すべきです。

• 単一DBのローカルトランザクションで足りる：DB自体のトランザクションで済むなら、Consensus Commitのメタデータ書き込みとgRPCの往復は余分なコストになる。1つのDBで水平スケールが必要なら、CockroachDBのような分散SQLやMySQL互換のTiDBの方が構成は単純になる。
• 結果整合性で業務が成り立つ：在庫の引当や通知のように、一時的な不整合を補償処理で戻せるなら、Sagaパターンと補償トランザクションで足り、商用ライセンスとKubernetesの運用を背負う理由は弱い。DB更新とイベント発行の不一致にはOutboxパターンを組み合わせる。
• Kubernetesを運用できない：本番のクラスタ構成はKubernetes前提で、この製品のためだけに導入するのは負担が大きい。その場合は、Community版のCoreをライブラリとして組み込み、1つのプロセス内で完結する範囲に絞る選択肢がある。
• 2PCインターフェースのまま当面動かしたい：3.20で削除されたため、3.19に留まると保守期限の制約を受ける。書き換えの工数を確保できないなら、移行計画が立つまで新規の分離クラスタ型を増やさない。

逆に、既存のRDBとNoSQLを載せ替えず、対象データへのアクセスをScalarDB経由にそろえたうえで両者をまたぐ更新をACIDで行いたい、しかもアプリケーションに補償処理を書きたくない、という条件がそろうなら有力な選択肢になります。トランザクションと分離レベルの基本はトランザクションとACID・分離レベルの解説で整理しています。

よくある質問

ScalarDB Clusterとは何ですか？

オープンソースのScalarDBを、Kubernetes上で複数ノードのサーバーとして動かす商用版です。種類の違うデータベースをまたぐ処理を1つのACIDトランザクションとして実行でき、ノード間の振り分けを自動で行います。Enterprise StandardとEnterprise Premiumの2エディションがあります。

ScalarDB CoreとScalarDB Clusterの違いは何ですか？

CoreはApache License 2.0のOSSで、アプリケーションにライブラリとして組み込んで使います。ClusterはCoreの機能をgRPCサーバーとしてクラスタ化したもので、リクエストの振り分けと認証・認可を備えます。SQLやGraphQLはClusterのPremium版でのみ使えます。

ScalarDB Clusterの最新バージョンはいくつですか？

2026年10月31日時点の最新は3.20.0（2026年10月30日公開）で、対応するHelm Chartは1.13.0です。同じ日に3.19.2・3.18.3・3.17.6・3.16.8の修正版も出ています。

ScalarDB Clusterの価格はいくらですか？

AWS Marketplaceの従量課金版では、2026年10月31日時点でEnterprise Standardが1ユニット1時間1.40ドル、Enterprise Premiumが2.79ドルです。1ユニットは2vCPU・4GBメモリのPod 1つで、最小構成の3 Podならライセンス分はStandardで1時間4.20ドルになります。インフラ費用は別で、従量課金版のPodは2vCPU・4GBメモリを超えて割り当てられません。

2フェーズコミットのインターフェースは使えなくなりましたか？

3.19で非推奨になり、3.20.0のライブラリからは消えています。3.19.2向けに書いた2PCのコードは3.20.0ではコンパイルできないため、共有クラスタ型の1フェーズコミットか、Transaction CoordinatorとGlobal Transaction APIを使う構成へ書き換えてから上げます。

関連記事

• Sagaパターンとは？補償トランザクション設計と実装方式の選び方を解説【2026年版】
• トランザクションとは？分離レベルの違い・ACID・commit/rollbackを実装目線で解説【2026年版】
• CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説
• TiDBとは：MySQL互換の分散SQLの仕組みとHTAP・検証手順・採用判断を解説
• Outboxパターンとは？DB更新とイベント発行を一致させる実装方式を解説【2026年版】