public previewのPostgreSQL互換TiDB Cloud Starterを触ってみた
こんにちは、ゲームソリューション部のsoraです。
今回は、2026年10月15日にpublic previewが始まった、PostgreSQL互換のTiDB Cloud Starterを触ってみたことについて書いていきます。
なお、本記事の内容は2026年10月27日時点のもので、public preview中のためGAで変わる可能性があります。
PostgreSQL互換のTiDB Cloud Starterとは
TiDB Cloud Starterを作るときに、MySQL互換とPostgreSQL互換を選べるようになりました。
PostgreSQLのワイヤープロトコルに対応していて、psqlや一般的なドライバからそのまま接続できます。
作成からpsqlでの接続までの手順は、PostgreSQL版のクイックスタートにまとまっています。
public previewの間は課金が有効になっておらず、組織ごとに10インスタンスまで無料枠の範囲で使えます。
1インスタンスあたりの無料枠は、行ストレージ50GiB、月500M RUです。
開発や評価向けの位置づけで、SLAは無く、本番での利用はGAを待つよう案内されています。
使えるリージョンはAWSのus-east-1（バージニア北部）だけです。
このあたりの条件は、FAQにまとまっています。
コンソールで見るMySQL版との違い
比較用に、同じプロジェクト、同じus-east-1にMySQL版のStarterも作って、画面を並べて見ていきます。
作成画面
My TiDBの「Create Resource」で「Starter」を選ぶと、その下に「Compatibility Mode」の選択肢が出ます。
PostgreSQL Compatibleには「PREVIEW」のラベルが付いています。
無料のインスタンスの数は別々に数えられていて、MySQL版は5個まで、PostgreSQL版は10個までです。
PostgreSQL Compatibleを選ぶと、リージョンはus-east-1だけになり、Capacityの代わりにFree Quotaの欄が出ます。
MySQL Compatibleを選ぶと、リージョンを選べて、CapacityとAdvanced Settingsの欄があります。
違いをまとめると、以下のとおりです。
| 項目 | MySQL Compatible | PostgreSQL Compatible |
|---|---|---|
| リージョン | 6個から選べる | us-east-1のみ |
| Capacity（Monthly Spending Limit） | あり | なし |
| Dual-layer Data Encryption | あり | なし |
| 無料枠（1インスタンスあたり） | 行ストレージ5GiB、列ストレージ5GiB、月50M RU | 行ストレージ50GiB、月500M RU |
概要ページとリソース一覧
作成してから1分ほどで、Statusが「Active」になりました。
PostgreSQL版の概要ページには、インスタンスの情報、Free Quota、Core Metricsだけが並んでいます。
MySQL版の概要ページには、使用量やspending limit、Code Examplesなども出ています。
PostgreSQL版には、TiDB Versionの行、RUの使用量、spending limit、Code Examplesなどがありません。
RUの使用量は、public previewの間はまだ表示されないとFAQに書かれています。
Core Metricsも、MySQL版の5つから、Query Per Second、Query Duration、Row-based Storageの3つになっていました。
リソース一覧には「Compatibility Mode」の列があり、MySQL版とPostgreSQL版が同じプロジェクトに並んでいても見分けられます。
左のメニュー
左のメニューは、PostgreSQL版の方が少なくなっています。
MySQL版は、DataやSettingsの下に子メニューがあります。
PostgreSQL版は、Overview、Backup、Monitoring、Networkingの4つだけです。
子メニューまで数えると、MySQL版は14項目、PostgreSQL版はMonitoringの下のMetricsとEventsを入れて6項目でした。
PostgreSQL版に無いのは、SQL Editor、Branches、Import、Export、Diagnosis、Integrationsです。
SQL EditorとImportが無いので、SQLの実行もデータの取り込みも、psqlなどのクライアントから行う形です。
MySQL版で「Data」の下にあるBackupと、「Settings」の下にあるNetworkingは、PostgreSQL版ではトップレベルのメニューになっていました。
MonitoringのMetricsは、Query Per Second、Query Duration、Connections、Row-based Storageの4つです。
接続情報
概要ページの「Connect」から接続ダイアログを開きます。
パスワードは、ダイアログの「Generate Password」で作ります。
「Connect With」の選択肢は、General、PostgreSQL CLI、Java (PostgreSQL Connector)、Python (pgclient)の4つでした。
MySQL版の接続ダイアログと比べてみます。
MySQL版はどのインスタンスでも同じホスト名で、プレフィックスはユーザー名にだけ付きます。
PostgreSQL版は、ホスト名の先頭にもユーザー名と同じプレフィックスが付き、ドメインにpgが入っていました。
ポートはPostgreSQLのデフォルトの5432です。
どちらも「Connections to this instance with public endpoint require TLS.」と書かれていて、TLSが必須になっています。
ネットワーク
PostgreSQL版のNetworkingには、Public Endpointの状態しかありません。
Public Endpointが「Enabled」で、「Currently accessible from any public IP address.」と表示されているだけでした。
MySQL版のNetworkingは以下です。
MySQL版では、パブリックエンドポイントを「Disable」で止めたり、Authorized NetworksでIPアドレスの範囲を絞ったり、AWS Private Endpointsを追加したりできます。
PostgreSQL版にはどれも無く、インターネットのどこからでも接続できる状態で固定されています。
プライベートエンドポイントに対応していないことは、FAQにも書かれています。
public previewの間は、パスワードとTLSだけで守る前提で使うことになります。
バックアップと復元
Backupを開くと、自動バックアップが1つ取られていました。
一覧の上には「Restore」と「Backup Setting」のボタンだけで、手動でバックアップを取るボタンはありません。
ドキュメントでも、Starterは手動バックアップに対応していないとされていて、MySQL版と同じです。
「Backup Setting」では、保持期間とバックアップの時刻を変えられます。
Backup Cycleは「Daily」で固定、保持期間はデフォルトの1日から30日まで延ばせて、時刻は30分単位で選べました。
MySQL版のStarterは、spending limitが0のままだと保持期間は1日です。
PostgreSQL版はspending limitが無い代わりに、spending limitを設定したMySQL版と同じ設定ができるようになっています。
「Restore」を押すと、復元先を指定する画面になります。
Restore Modeは「Snapshot Restore」だけで、Point-in-Time RestoreはMySQL版のStarterと同じく使えません。
Compatibility ModeではMySQL Compatibleがグレーアウトしていて、PostgreSQL版のバックアップはPostgreSQL版のインスタンスにだけ復元できます。
復元を実行すると、新しいPostgreSQL版のインスタンスが作られました。
psqlからの確認
ここからは、手元のMacからpsqlで接続して確認していきます。
psqlのインストール
Macにはpsqlが入っていなかったので、Homebrewでlibpqを入れます。
brew install libpq
libpqはkeg-onlyで/opt/homebrew/binにはリンクされないので、PATHを通しておきます。
echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc
export PATH="/opt/homebrew/opt/libpq/bin:$PATH"
psql --version
psql (PostgreSQL) 18.6
接続
接続ダイアログの値をもとに、接続情報を環境変数に入れて接続します。
データベースはダイアログでは<DB>のままだったので、postgresを指定しました。
export PG_CONN="host=<プレフィックス>.gateway01.us-east-1.prod.aws.pg.tidbcloud.com port=5432 user=<プレフィックス>.postgres dbname=postgres sslmode=verify-full sslrootcert=/etc/ssl/cert.pem"
export PGPASSWORD='<パスワード>'
psql "$PG_CONN"
psql (18.6, server 17.0)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: postgresql)
Type "help" for help.
postgres=#
そのまま接続できました。
サーバーのバージョンは17.0と表示されています。
PostgreSQLとしての確認
エラーのSQLSTATEも見たいので、\set VERBOSITY verboseにしておきます。
エラーを詳しく表示する設定で、SQLSTATE（エラーの種類を表す5文字のコード）も出るようになります。
\set VERBOSITY verbose
バージョンや接続中のユーザーなどを見てみます。
SELECT version();
SHOW server_version;
SELECT current_user, current_database(), current_schema();
SHOW is_superuser;
SHOW transaction_isolation;
SELECT tidb_version();
version
--------------------------------------------------------------------------------------
PostgreSQL 17.0 (TiDB Cloud Starter with PostgreSQL compatibility. 20261025-9b35dd3)
(1 row)
server_version
----------------
17.0
(1 row)
current_user | current_database | current_schema
--------------+------------------+----------------
postgres | postgres | public
(1 row)
is_superuser
--------------
on
(1 row)
transaction_isolation
-----------------------
read committed
(1 row)
ERROR: 42883: function tidb_version() does not exist
version()はPostgreSQL 17.0を名乗りつつ、括弧の中に「TiDB Cloud Starter with PostgreSQL compatibility」と書かれていました。
MySQL版のVERSION()は8.0.11-TiDB-v8.5.3-serverlessでTiDBのバージョンが見えますが、PostgreSQL版では見えません。
MySQL版で使えるtidb_version()も、PostgreSQL版には無く、PostgreSQLと同じSQLSTATEの42883（関数が存在しない）が返ります。
current_userはpostgresで、接続に使ったユーザー名からプレフィックスが外れています。
デフォルトの分離レベルはread committedで、PostgreSQLのデフォルトと同じです。
次に、psqlのメタコマンドを試します。
\l
\dn
\du
\dt
\dx
List of databases
Name | Owner | Encoding | Locale Provider | Collate | Ctype | Locale | ICU Rules | Access privileges
----------+----------+----------+-----------------+---------+-------+--------+-----------+-------------------
postgres | postgres | UTF8 | libc | C | C | | |
(1 row)
List of schemas
Name | Owner
--------+----------
public | postgres
(1 row)
List of roles
Role name | Attributes
-----------+-----------------------------------
postgres | Superuser, Create role, Create DB
List of tables
Schema | Name | Type | Owner
--------+---------------------------------+-------+----------
public | tidbcloud_com_cell_principals | table | postgres
public | tidbcloud_com_cell_sql_receipts | table | postgres
public | tidbcloud_com_cell_sql_versions | table | postgres
(3 rows)
List of installed extensions
Name | Version | Default version | Schema | Description
------+---------+-----------------+--------+-------------
(0 rows)
\l、\dn、\du、\dt、\dxなどのメタコマンドは、どれもエラーにならずに動きました。
データベースはpostgresだけで、PostgreSQLにあるtemplate0、template1はありません。
template0、template1は、CREATE DATABASEで新しいデータベースを作るときにコピー元になる雛形のデータベースです。
PostgreSQL版には無いですが、このあと試したCREATE DATABASEは問題なく通りました。
\dtには、tidbcloud_com_cell_*の3つのテーブルが出ています。
TiDB Cloudがデータベースユーザーの管理に使っているテーブルなので、変更や削除はしないでおきます。
\dxの拡張は0件でした。
plpgsqlは、PostgreSQLで関数やプロシージャを書くための言語のPL/pgSQLです。
PostgreSQLでは最初から拡張として入っていて\dxに出ますが、ここでは出ていません。
PostgreSQL版もPL/pgSQLの関数やプロシージャには対応しているので、使えないのではなく、拡張として登録されていない形です。
本家のPostgreSQLとの違い
PostgreSQL版で使えない機能は、公式の互換性ページにまとまっています。
テーブル継承、外部データラッパー（FDW）、論理レプリケーション、XML型などが対象外です。
今回は、その中からテーブル継承、PostGIS（サードパーティの拡張）、SERIALIZABLEの3つを試してみます。
postgresデータベースには先ほどのtidbcloud_com_cell_*のテーブルがあるので、検証用のデータベースを作って移動しておきます。
CREATE DATABASE trial;
\c trial
テーブル継承
CREATE TABLE base_items (id INT PRIMARY KEY, name TEXT);
CREATE TABLE special_items (note TEXT) INHERITS (base_items);
CREATE TABLE
ERROR: 42601: syntax error at or near "INHERITS"
LINE 1: CREATE TABLE special_items (note TEXT) INHERITS (base_items)...
^
親のテーブルは作れましたが、INHERITSは構文エラーになりました。
PostGIS
CREATE EXTENSION postgis;
ERROR: 42704: extension is not available
使える拡張は、TiDB Cloudが対応しているものだけです。
対応している拡張の一覧には、vector（pgvector互換）やuuid-osspなどがありますが、PostGISはありません。
SERIALIZABLE
BEGIN ISOLATION LEVEL SERIALIZABLE;
SHOW transaction_isolation;
COMMIT;
WARNING: 01000: SERIALIZABLE has been downgraded to REPEATABLE READ
BEGIN
transaction_isolation
-----------------------
repeatable read
(1 row)
COMMIT
SERIALIZABLEはエラーにならず、警告を出してREPEATABLE READに下がりました。
互換性ページの記載どおりですが、警告を見ていないとSERIALIZABLEのつもりで動かしてしまいます。
3つの中では、移行のときに一番気づきにくいところだと思います。
最後に
今回は、public previewのPostgreSQL互換のTiDB Cloud Starterで、コンソールでのMySQL版との違いと、psqlからPostgreSQLとしてどう見えるかを確認してみました。
この記事がどなたかの参考になれば幸いです。
