walshadow は 2026 年 9 月時点で Development Preview です。README には、本番で使う前に自分のワークロードで十分に検証するよう求める警告があります1。この記事は検証環境で試した結果です。
1. はじめに
ClickHouse が 2026 年に公開した walshadow2 は、PostgreSQL の変更を ClickHouse に複製するツールです。同様のツールには Debezium や PeerDB などがありますが、walshadow はデータの取り出し方が違います。
walshadow replicates PostgreSQL rows into ClickHouse from physical WAL
README の一文です。物理 WAL は、PostgreSQL がデータファイルのページに加えた変更をそのまま記録したログです。既存のツールは、PostgreSQL にこのログを行単位の変更へ変換させる logical decoding（論理デコード）を使い、walshadow は物理 WAL を直接読みます。
物理 WAL を読むには、ソースに物理レプリケーション接続を張る必要があります。マネージドの PostgreSQL では、これが利用者に開放されているとは限りません。walshadow を紹介する公式ブログにも、多くのマネージド PostgreSQL は物理 WAL を利用者に開放しておらず walshadow を使えない、とあります3。たとえば Amazon RDS for PostgreSQL で付与される rds_replication ロールの権限は、「論理スロットの管理と、論理スロットによるストリーミング」です4。物理レプリケーション接続を利用者に開放する記述は見つけられませんでした（2026 年 9 月時点）。
一方、ClickHouse が提供している ClickHouse Managed Postgres は、公式ドキュメントに「full superuser access」とあります5。それなら walshadow の前提を満たせるかもしれません。宛先も ClickHouse Cloud にすれば、両端ともマネージドのまま物理 WAL で複製する構成になります。これを試しました。
なお同じ Managed Postgres から ClickHouse への経路は、以前 ClickPipes（ClickHouse Cloud のデータ取り込みサービス）の CDC（変更データキャプチャ）で遅延を測ったことがあります6。今回は同じ経路を、別の仕組みで複製します。
比較のため、ソース・宛先・walshadow をすべて手元の Docker で動かした構成でも同じ検証をしました。以下ではこれを「コンテナ版」と呼びます。
1.1. 結論（先出し）
- ClickHouse Managed Postgres に物理レプリケーション接続を張り、walshadow で ClickHouse Cloud まで複製できた。superuser なのでレプリケーション接続ができ、IP allowlist で許可した接続元からインターネット経由で張れる。ソース（aarch64）と walshadow 側（x86_64）のアーキテクチャが違う構成だが、今回の 1 ケースでは動いた
- PostgreSQL が別テーブル（TOAST テーブル）に移して保存する大きな列は、その列を変更しない UPDATE のあとも ClickHouse Cloud に複製された。ソースと宛先で md5 が一致した
- ソース側にはレプリケーションスロットもデコードの作業領域も発生しなかった。デコードとディスクへの書き出しは walshadow のホストで行われる
- コンテナ版と違ったのは、大きな値が TOAST テーブルに移るかどうかだった。Managed Postgres は圧縮方式が lz4 で、同じ値が 803 バイトに圧縮されて元のテーブルの行に収まった
1.2. 検証ゴール
| # | 確かめること | 確認できれば OK の条件 |
|---|---|---|
| 1 | マネージドの PostgreSQL から物理 WAL を受け取れるか | 物理レプリケーション接続ができ、walshadow の初期ロードが完了する |
| 2 | 大きな列の値が ClickHouse Cloud に複製されるか | 大きな列を変更しない UPDATE のあと、ソースと ClickHouse で大きな列の md5 と長さが一致する |
| 3 | コンテナ版と挙動が変わる点はあるか | 変わった箇所を特定し、原因まで示せる |
2. 検証環境
| 項目 | 内容 |
|---|---|
| ソース | ClickHouse Managed Postgres（AWS では public beta7）、PostgreSQL 18.6（aarch64）、2 vCPU・メモリ 16 GB、スタンバイなし、AWS 東京リージョン |
| 宛先 | ClickHouse Cloud 26.4.1、3 vCPU・メモリ 12 GiB × 1 レプリカ、AWS 東京リージョン |
| walshadow | commit cf77c2cf61d1d28ead17284d41662d09ca1a4027
|
| walshadow を動かすホスト | Amazon EC2 t3.medium（2 vCPU・メモリ 4 GiB、x86_64）、Amazon Linux 2023、Docker 25.0.14、AWS 東京リージョン |
| コンテナ版（比較用） | Windows 11 Pro 上の Docker Desktop で、postgres:18-alpine（18.6）と clickhouse/clickhouse-server:26.3-alpine。付録の logical decoding の確認は postgres:17
|
walshadow 本体は、ソース・宛先と同じ AWS 東京リージョンの EC2 に置き、Docker で動かしています。WAL はリージョンの外に出ません。ソースと宛先はマネージドで、walshadow は自分で運用する構成です。レプリケーションスロットは設定せず、スロットを使わない構成で動かしています。
接続はすべて EC2 から張ります。ソースへはデータの流れと逆向きに 5432 番へ、宛先へは 9440 番へ、どちらも TLS で接続します。そのため、ソースと宛先の IP allowlist に EC2 の Elastic IP を登録しました。EC2 のセキュリティグループには、受け付ける通信（inbound）の許可はありません。配置とスペック、接続の向きは 3 章の図 1 にもまとめています。
ソースと宛先には、パブリックのエンドポイントで接続しています。どちらも AWS PrivateLink に対応していますが、Managed Postgres ではサポートに依頼して手動で設定してもらう必要があり8、ClickHouse Cloud では Scale と Enterprise のプランの機能です9。今回は検証なので、IP allowlist で接続元を EC2 の Elastic IP に絞る構成にしました。PrivateLink を使った構成は試していません。
なお walshadow には、ClickHouse Managed Postgres に組み込んだマネージド版もあり、2026 年 9 月時点では申し込み制の private preview です3。この記事ではマネージド版は使わず、walshadow を EC2 に自分で立てています。
EC2 は x86_64 の t3.medium を使いました。ソースと同じ aarch64 の EC2（Graviton）にすればアーキテクチャをそろえられますが、今回は試していません。
3. walshadow の仕組み
logical decoding を使うツールは、PostgreSQL 自身にデコードさせて、組み立て済みの行を受け取ります。walshadow は PostgreSQL にデコードさせず、行の組み立てを walshadow 自身が行います。そのためには、WAL を書いた時点のカタログ（列の並び・型・TOAST の定義）が必要です。walshadow はこれを、内部に置いた PostgreSQL に WAL をリプレイさせて用意します。この PostgreSQL を shadow PostgreSQL（以下 shadow）と呼びます。WAL を読んで行を組み立てる常駐プロセスは walshadow-stream です。全体の構成を図 1 に示します。図の TOAST ミラーは 5.2 章で説明します。
図 1: walshadow の構成と今回の配置。3 つとも AWS 東京リージョンにあり、shadow はカタログを再現するためだけに置かれ、ユーザーテーブルの中身は持たない
Physical tuples need catalog state from when they were written. A static schema snapshot cannot follow DDL or relation rewrites.
architecture/README.md の「Why a shadow」にある説明です10。スキーマのスナップショットを 1 枚持つだけでは、DDL や、VACUUM FULL などでテーブルのファイルが作り直される変化を反映できないので、PostgreSQL 自身にリプレイさせる設計です。
shadow に渡される WAL は、そのままのコピーではありません。ユーザーテーブルのレコードは no-op（何もしないレコード）に置き換えられ、WAL 上の位置だけが保たれた状態で渡されます。以下、これをフィルタ済みの WAL と呼びます。同じドキュメントには Shadow retains catalogs and recovery state, not ordinary user-table contents とあり、shadow が持つのはカタログとリカバリの状態だけです。
shadow は walshadow が起動して管理するので、利用者が別途 PostgreSQL を用意する必要はありません。同梱の docker/docker-compose.yml の冒頭にも One service: the daemon, plus the shadow PG it owns inside the container と書かれています11。
4. つなぐまでの手順
4.1. なぜマネージドで動くのか
walshadow がソースに求めるのは、REPLICATION 権限を持つアカウントと、wal_level = logical、WAL センダー（walsender）が 2 つ以上という条件です12。REPLICATION 権限はロールの属性で、superuser であればこの属性が無くてもレプリケーション接続ができます13。
Managed Postgres で使えるアカウントがこの条件を満たすか確かめました。
SELECT version();
SHOW wal_level;
SHOW max_wal_senders;
SELECT current_user, usesuper FROM pg_user WHERE usename = current_user;
PostgreSQL 18.6 (Ubuntu 18.6-1.pgdg22.04+2) on aarch64-unknown-linux-gnu ...
wal_level | logical
max_wal_senders | 10
current_user | postgres
usesuper | t
usesuper = t で、wal_level は最初から logical、max_wal_senders も 10 で 2 つ以上の条件を満たしていました。ClickPipes の CDC を標準機能として持っているので、そのために有効になっているのだと考えられます。設定の変更は何も必要ありませんでした。
権限があっても、接続経路が開いていなければ使えません。物理レプリケーション接続を直接試します。
psql "host=<エンドポイント> port=5432 user=postgres dbname=postgres sslmode=require replication=true" \
-c "IDENTIFY_SYSTEM;"
systemid | timeline | xlogpos | dbname
---------------------+----------+-----------+--------
7687877882450283644 | 1 | 0/302AC00 |
IDENTIFY_SYSTEM が応答しました。replication=true は物理レプリケーション用の接続を開く指定（論理レプリケーション用は replication=database）なので、物理レプリケーション接続が受け付けられたことを示します。
接続は PostgreSQL へ直接（5432 番）行っています。公式ドキュメントには、長時間の接続や、コネクションプーリングに対応しない機能を使う場合はダイレクト接続を使うよう書かれています14。
コネクションプーリング用の接続先（6432 番、PgBouncer 1.25.2）でも、replication=true の接続で IDENTIFY_SYSTEM が応答しました。ただし walshadow 本体をプール経由で動かす検証まではしていないので、この記事ではダイレクト接続を使っています。
4.2. 接続確認から起動まで
walshadow には接続先を URL で渡します。walshadow は ClickHouse に Native プロトコルで接続するので、TLS の clickhouses:// と 9440 番を指定します（8443 番は HTTP インターフェースで用途が違います）。
export WALSHADOW_PG_URL="postgres://postgres:***@<pg エンドポイント>:5432/postgres?sslmode=require"
export WALSHADOW_CH_URL="clickhouses://default:***@<ch エンドポイント>:9440/walshadow"
docker compose -f docker/docker-compose.yml run --rm walshadow init --all-tables
init は両端に接続して前提条件を点検し、結果を並べます。
source <pg エンドポイント>:5432/postgres
✓ reachable, PostgreSQL 18.6
✓ wal_level = logical, server_version_num ≥ 160000
✓ postgres may start replication
destination <ch エンドポイント>:9440
✓ reachable, ClickHouse 26.4.1
✓ created database walshadow
postgres may start replication が出れば、4.1 章で確かめたことを walshadow 自身も確認できたことになります。起動します。
docker compose -f docker/docker-compose.yml up -d
shadow caught up to bootstrap end_lsn replay_lsn="0/D80002B8"
bridge connected socket=/var/run/postgresql/walshadow-bridge.sock workers=3 pg_version=180006 in_recovery=true
backfill complete; converged once WAL apply passes p_hi qname=public.toasttest rows=1 copied=true
初期ロードが完了しました。
4.3. アーキテクチャの違い
ソースの PostgreSQL は aarch64-unknown-linux-gnu で、walshadow のホストと shadow は x86_64 です。shadow はソースの WAL をリプレイするので、アーキテクチャが違うとリプレイできない可能性がありました。PostgreSQL の公式ドキュメントのログシッピングの節には the hardware architecture must be the same とあります15。
起動ログでは、walshadow-stream と shadow の接続（ログの bridge connected）が in_recovery=true で確立し、初期ロードも完了しています。公式の条件から外れた構成なので、今回の構成では動いたという範囲で受け取り、この挙動に頼ることは勧めません。
5. 実行結果
5.1. 変更しない大きな列の値も複製される
walshadow を使う動機のひとつは、logical decoding では出力に入らない大きな列の値も複製できることです。PostgreSQL は大きな値を別のテーブル（TOAST テーブル）に移して保存しますが16、その列を変更しない UPDATE をすると、logical decoding の出力に値が入りません（REPLICA IDENTITY がデフォルトの場合）。実際の出力は付録に載せています。
検証用の toasttest には、md5 の文字列を連結した 75,008 バイトの値を blob 列に 1 行入れてあります。この値は圧縮しても縮まず、Managed Postgres でも保存後のサイズが 75,008 バイトのまま TOAST テーブルに移っています。宛先の TOAST ミラー（5.2 章）には、この値のチャンクが 38 行入っていました。
この表で、logical decoding なら値が出力に入らない条件の UPDATE を実行しました。
UPDATE toasttest SET tag = 'c' WHERE id = 1; -- blob は変更しない
| 項目 | ソース（Managed Postgres） | ClickHouse Cloud（FINAL） |
|---|---|---|
md5(blob) |
408530f95389c7c490ef1c746d6914d8 |
408530f95389c7c490ef1c746d6914d8 |
length(blob) |
75,008 | 75,008 |
tag |
c | c |
blob は md5 の文字列（ASCII）を連結した値なので、length(blob) はソースの文字数と ClickHouse のバイト数が同じ値になります。ClickHouse 側は ReplacingMergeTree 系のテーブルで、同じ行の古いバージョンはバックグラウンドのマージで後から消えます。そのため FINAL を付けて最新の行だけを読んでいます。
walshadow が各行に付ける WAL 位置の列 _lsn は UPDATE の前後で進んでおり、初期ロード時の行をそのまま見ているわけではありません。ゴール 1 と 2 は OK です。
5.2. 複製できる仕組みは宛先の TOAST ミラー
なぜ複製できるのかは、宛先のテーブル一覧を見ると分かります。ソースの toasttest に対応するテーブルのほかに、pg_toast_18015 というテーブルが自動で作られていました。
SELECT name, engine FROM system.tables WHERE database = 'walshadow';
pg_toast_18015 SharedReplacingMergeTree
toasttest SharedReplacingMergeTree
PostgreSQL の TOAST テーブルの中身（チャンク）を、ClickHouse 側にコピーしたテーブルです。以下これを TOAST ミラーと呼びます。walshadow の limitations.md にも ClickHouse output always uses persistent TOAST chunk mirrors とあり、ClickHouse への出力では常にこの仕組みを使います17。その列を変更しない UPDATE では値が WAL に載りませんが、それでも行を組み立てられるのは、宛先にチャンクのコピーを持っているからです。
その代わり宛先の容量が増えます。toasttest と同じ作り方の 75,008 バイトの値を 500 行入れた表で測ったところ、ユーザーテーブル 18.17 MiB に対して TOAST ミラーが 17.94 MiB で、同じ値を 2 か所に持つことになります。ClickHouse 側ではどちらも元の約半分に圧縮されていますが（圧縮前は 35.78 MiB と 36.31 MiB）、PostgreSQL の TOAST の圧縮では縮まない値です。
なお宛先のエンジンが SharedReplacingMergeTree になっているのは、ClickHouse Cloud では MergeTree 系のエンジンが Shared 系に置き換わるためで18、walshadow の設定によるものではありません。walshadow が出す定義はコンテナ版と同じ ReplacingMergeTree(_lsn, _is_deleted) です。
5.3. 圧縮方式で変わった点
コンテナ版と違ったのは、大きな値が TOAST テーブルに移るかどうかでした。
コンテナ版では repeat('X', 200000) を入れると値が TOAST テーブルに移りましたが、Managed Postgres では同じ値が元のテーブルの行に残りました。保存後のサイズを比べると理由が分かります。
| 環境 | default_toast_compression |
保存後のサイズ | TOAST テーブルに移ったか |
|---|---|---|---|
コンテナ版（postgres:18-alpine） |
pglz | 2,296 バイト | 移った |
| ClickHouse Managed Postgres 18.6 | lz4 | 803 バイト | 移らなかった |
PostgreSQL のドキュメントによると、TOAST の処理が始まる条件は圧縮前の行の幅です16。
The TOAST management code is triggered only when a row value to be stored in a table is wider than
TOAST_TUPLE_THRESHOLDbytes (normally 2 kB).
始まったあとは、次の順に進みます。
The TOAST code will compress and/or move field values out-of-line until the row value is shorter than
TOAST_TUPLE_TARGETbytes ... Compression will be attempted first, then out-of-line storage if the row is still too big.
20 万文字の値は、どちらの環境でも TOAST の処理そのものは始まります。そのうえで lz4 は 803 バイトまで圧縮したので元のテーブルの行に収まり、TOAST テーブルには移りませんでした。値が元のテーブルの行にあれば、変更しない列の値が logical decoding の出力に入らない現象（5.1 章）の対象にもなりません。
圧縮できる値は TOAST テーブルに移らないことがあるので、この記事の検証では圧縮しても縮まない値（md5 の文字列を連結したもの）を使っています。コンテナ版と変わった点を特定し、原因まで示せたので、ゴール 3 も OK です。
6. 考察
6.1. この構成が成り立つ条件
今回つながったのは、使えるアカウントが superuser でレプリケーション接続ができたこと、wal_level が最初から logical だったこと、物理レプリケーション接続を IP allowlist で許可した接続元から張れたこと、の 3 点がそろっていたからです。どれか 1 つでも欠ければ walshadow は使えません。
RDS では、1 つ目（レプリケーション接続ができるアカウント）と 3 つ目（物理レプリケーション接続の開放）を公式ドキュメントからは確かめられません。付与される rds_replication ロールの権限は論理スロットに限られ4、物理レプリケーション接続を開放する記述も見つけられませんでした。REPLICATION 権限（または superuser）と wal_level = logical を利用者が用意でき、物理レプリケーション接続も開放しているサービスであれば、マネージドであっても同じ構成を使えると考えられます。
アーキテクチャについては、4.3 章のとおり公式の条件から外れた構成で、aarch64 から x86_64 の 1 ケースで動いたというだけです。ソースと違うアーキテクチャのホストで shadow を動かすなら、事前に同じ組み合わせで確かめる必要があります。
6.2. 使うときの注意
- ソースで
REPLICATION権限（または superuser）が使え、wal_level = logicalで、物理レプリケーション接続が開いていることを先に確かめる。replication=trueの接続でIDENTIFY_SYSTEMを 1 回実行すれば判断できる - 圧縮できない大きな列が多いなら、宛先の容量はユーザーテーブルのおよそ 2 倍で見積もる。TOAST ミラーを持つため
- 宛先は
ReplacingMergeTree系なので、最新の状態を読むクエリにはFINALが必要
walshadow の limitations.md には未サポートの条件が並んでいるので、検討する場合は先に読むことをおすすめします17。
ClickPipes の Postgres CDC との使い分けについて、公式は基準を示していません（2026 年 9 月時点）。公式ブログにあるのは、ClickPipes の基になっている PeerDB とのベンチマーク（遅延は walshadow が約 200 ms、PeerDB が約 10 秒）だけです3。
6.3. ソース側にかかる負荷
物理 WAL を読むことで、ソースにかかる負荷も logical decoding とは変わります。
logical decoding で使うレプリケーションスロットは、必要な WAL とシステムカタログの行をソースに保持させます。
This consumes storage because neither required WAL nor required rows from the system catalogs can be removed by
VACUUMas long as they are required by a replication slot.19
WAL だけでなく、システムカタログの不要行も VACUUM で消せなくなります。デコードの作業領域もソースに置かれます。
logical_decoding_work_mem... Specifies the maximum amount of memory to be used by logical decoding, before some of the decoded changes are written to local disk.20
デフォルトは 64 MB で、超えた分はソースのローカルディスクに書き出されます。大きなトランザクションほど書き出す量が増えます。
今回の構成（スロットを使わない構成）のソース側では、どちらも発生していません。
SELECT slot_name, slot_type FROM pg_replication_slots;
SELECT backend_type, query FROM pg_stat_activity WHERE backend_type = 'walsender';
(0 rows)
walsender | START_REPLICATION 0/D8000000 TIMELINE 1
スロットは 1 つもなく、walsender が実行しているのは START_REPLICATION ... TIMELINE 1、つまりスロットを使わない物理ストリーミングです。ソースは WAL を読んで送るだけで、デコードはしていません。
デコード、トランザクションのバッファ、ディスクへの書き出しは walshadow のホストで行われます。5.2 章の 500 行の表を複製した時点で、稼働中のコンテナを測った結果を図 2 にまとめました。
図 2: ソースと walshadow のホストの負荷。デコード・バッファ・ディスクへの書き出しはすべて walshadow のホストで行われ、ソースは WAL を送るだけになる
ディスクの合計 386.4 MiB のうち、349.7 MiB は WAL を 2 か所に持っている分です（フィルタ済みの WAL を置く out が 237.7 MiB、shadow の pg_wal が 112.0 MiB）。カタログの実体（shadow の base）は 29.8 MiB です。複製した 500 行の表だけでも圧縮前で約 35.8 MiB あるので、shadow がユーザーデータを持たないことと一致します。残りの 6.9 MiB は shadow のログなどです。
スロットを使わない構成には注意点があります。walshadow のドキュメントには Without slot, ensure wal_keep_size or continuous archive covers worst-case outage and backlog. Missing source WAL stops replication rather than skipping data とあります21。ソースが先に WAL を消すと、データを飛ばさずに止まります。同じドキュメントには Configure a physical replication slot for routine deployments ともあり、通常の運用では物理レプリケーションスロットを作る構成が書かれています。その場合、walshadow が読み終えていない WAL はスロットによってソースに保持されます。この記事で測ったのはスロットを使わない構成で、物理スロットを使ったときのソース側の負荷は確かめていません。
なお wal_level = logical にすると、logical decoding に必要な情報が WAL に追加で書かれます22。walshadow もソースに wal_level = logical を求めるので、この分の WAL の増加は物理 WAL を読んでも避けられません。
7. まとめ
ClickHouse Managed Postgres から物理 WAL を受け取り、ClickHouse Cloud まで複製できました。条件は、REPLICATION 権限を満たすアカウント（今回は superuser）が使えること、wal_level = logical であること、物理レプリケーション接続を walshadow のホストから張れることの 3 点です。ソース側にはスロットもデコードの作業領域も発生せず、デコードは walshadow のホストで行われました。
大きな列を変更しない UPDATE のあとも、その列は md5 が一致する状態で複製されました。ソースと shadow のアーキテクチャが違う構成も、今回の 1 ケースではリプレイできました。ただし PostgreSQL の公式ドキュメントが求める条件からは外れています。
一方で、Managed Postgres は default_toast_compression が lz4 でコンテナ版（pglz）と違い、大きな値が TOAST テーブルに移るかどうかが変わりました。大きな列を検証するときは、ソースの圧縮方式を確かめ、圧縮しても縮まない値でデータを作る必要があります。
8. 付録（コンテナ版で確かめたこと）
本文で前提にした「logical decoding では大きな列の値が出力に入らない」を、手元の Docker で確かめた結果です。
postgres:17 で、PostgreSQL 同梱のテスト用出力プラグイン test_decoding のスロットを作り、TOAST された blob を変更せずに tag だけ UPDATE しました。
table public.t: UPDATE: id[integer]:1 tag[text]:'b' blob[text]:unchanged-toast-datum
blob の値の代わりに unchanged-toast-datum が出ています。標準の論理レプリケーション（PUBLICATION と SUBSCRIPTION）が使う pgoutput でも同じで、バイト列を見ると列のマーカーが 0x75（u、unchanged の意味）で、値の本体が続きません。
同じ UPDATE をコンテナ版の walshadow で複製すると、ソースと ClickHouse で md5 が一致しました。宛先には本文と同じように TOAST ミラーが作られ、ユーザーテーブルとほぼ同じ容量を占めます。
スキーマ変更は、列の追加（デフォルト値ごと）と改名が反映されることを確かめました。TRUNCATE も反映されました。列の型変更は今回試していませんが、schema-changes.md には警告を出すだけで、手作業の移行が必要と書かれています23。
参考
ClickHouse、ClickHouse のロゴ、および関連するマークは、ClickHouse, Inc. またはその関連会社の商標または登録商標です（https://clickhouse.com）。
-
ClickHouse/walshadow の README（Project status: Development Preview の警告） ↩
-
Introducing WalShadow（ClickHouse ブログ）（Bringing WalShadow to ClickHouse Managed Postgres の節と、PeerDB とのベンチマーク） ↩ ↩2 ↩3
-
Amazon RDS for PostgreSQL の論理レプリケーションの実行（rds_replication ロールの権限範囲） ↩ ↩2
-
ClickHouse Managed Postgres FAQ（superuser access について） ↩
-
ClickHouse Managed Postgres の CDC はどれくらい速い? Postgres→ClickHouse の増分レプリ遅延を実測してみた ↩
-
ClickHouse Managed Postgres のクイックスタート（AWS では public beta、GCP は Private Preview） ↩
-
ClickHouse Managed Postgres のセキュリティ（AWS PrivateLink はサポートによる手動設定、IP フィルタ） ↩
-
ClickHouse Cloud の AWS PrivateLink（Scale と Enterprise のプランで利用可） ↩
-
ClickHouse/walshadow の architecture/README.md「Why a shadow」 ↩
-
ClickHouse/walshadow の docs/getting-started.md「Before starting」 ↩
-
PostgreSQL 公式ドキュメント 21.2. Role Attributes（REPLICATION 属性と superuser） ↩
-
ClickHouse Managed Postgres の接続（プール経由とダイレクト） ↩
-
PostgreSQL 公式ドキュメント 26.2. Log-Shipping Standby Servers（26.2.1. Planning） ↩
-
ClickHouse/walshadow の docs/limitations.md「Large values」 ↩ ↩2
-
PostgreSQL 公式ドキュメント 47.2. Logical Decoding Concepts（Replication Slots） ↩
-
PostgreSQL 公式ドキュメント 19.4. Resource Consumption（logical_decoding_work_mem） ↩
-
ClickHouse/walshadow の docs/operations.md「Retain source WAL」 ↩
-
PostgreSQL 公式ドキュメント 19.5. Write Ahead Log（wal_level） ↩
-
ClickHouse/walshadow の docs/schema-changes.md「Behavior matrix」（スキーマ変更ごとの動作の一覧） ↩