Cloud SQL 與 Cloud Spanner 簡介
Cloud SQL 與 Cloud Spanner 是 Google Cloud 兩大旗艦關聯式資料庫平台，PCD 考試會明確要求開發者知道每個服務該在什麼時機選用。Cloud SQL 是針對 MySQL 5.7/8.0、PostgreSQL 12-16 以及 SQL Server 2017/2019/2022 的全代管服務，與你應用程式現有依賴的開源引擎完全相容。Cloud Spanner 則是水平可擴充、具備 external consistency 的關聯式資料庫，支援同步式全球複寫，並提供 99.999% 的 multi-region SLA。
這份學習筆記涵蓋開發者會面對的完整面向：Cloud SQL HA 拓撲與故障轉移行為、Cloud SQL Auth Proxy 與 IAM 資料庫驗證、同區域與跨區域讀取副本、AlloyDB 的 columnar engine 何時勝過原生 PostgreSQL、Spanner regional 與 multi-region instance configurations、interleaved tables 與 STORING index、透過 BigQuery external dataset 查詢 Spanner、用於 CDC 的 Spanner change streams、備份與 PITR 語意，以及 Cloud SQL 維護視窗搭配 denylist days 來實作變更凍結期。
白話文解釋
以下三個比喻能幫你在考試之前就把 Cloud SQL 與 Spanner 的決策樹打通。
街角的咖啡店 vs 全球連鎖咖啡品牌
Cloud SQL 就像街角一家備受喜愛的咖啡店。一位咖啡師（主要實例）負責所有訂單，後場倉庫還有一位備援咖啡師（位於另一個可用區的 HA 待機），可以在大約 90 秒內接手。這家店反應快、熟悉客人，一天能服務數千位客人——但櫃台一次只能做一杯飲料。Cloud Spanner 則像全球的 Starbucks：橫跨數十個國家、上千家門市，每家門市以毫秒等級共享同一份食譜，你在台北點的 venti latte 會自動從二十分鐘前在西雅圖刷的同一張會員卡扣款。每杯飲料的單價較高，但若你需要全球一致的下單流程與無上限的櫃台吞吐量，任何單一門市都無法取代整個連鎖品牌。
公寓租約 vs 摩天大樓租約
跑在 Cloud SQL 上像是租公寓：房東（Google）會處理水管、電線與整棟大樓的維護排程。半夜熱水器壞掉可以打電話給他（自動 failover），但如果你家人口擴展到五十人，你沒辦法「加蓋一翼」——必須整戶搬到更大的單位（垂直擴充，伴隨短暫停機）。Spanner 則是租摩天大樓的樓層。當你需要更多空間時，電梯直接給你下一層樓（多加一個 node）——同一個地址、同一份廚房食譜、同一組門鎖，只是面積變大。摩天大樓永遠不需要為了翻修而關閉，因為每一層樓從第一天就被設計成可以熱插拔。
備份影印機 vs 時光機
Cloud SQL 的自動備份與 point-in-time recovery 感覺像是備份影印機——你會有一份凌晨 2 點的文件快照，加上一疊可以重播以重建任意中間狀態的 binary log。Spanner 的 PITR 則更像時光機：任何讀取都可以指定「請給我昨天 14:32:08 UTC 那個瞬間的這張表」，資料庫會直接回傳那個一致性快照，根本不需要做 restore，因為所有寫入都已經由 TrueTime 時間戳記版本化。目標相同（從人為失誤中恢復），但機制完全不同——在考試裡，「從備份還原」（Cloud SQL）與「使用 READ_TIMESTAMP 做 stale read」（Spanner）的差異是常見的迷惑選項。
Cloud SQL 高可用性與故障轉移
Cloud Spanner 最強的一致性保證：每一筆 transaction 都會獲得全域排序的 TrueTime commit timestamp，後續任何讀取都會看見所有比其 read timestamp 還早 commit 的 transaction 結果——無論讀取由哪個 region 或 replica 提供。比 serializability 更強，因為這個順序與真實 wall-clock 時間吻合，這也是 Spanner 能在跨 region 提供強一致讀取的同時維持 99.999% SLA 的關鍵。詳見 Spanner TrueTime and external consistency。
Cloud SQL HA 配置是正式環境的基準。它必須在建立時主動勾選 Multiple zones (highly available)，或透過 gcloud sql instances patch ... --availability-type=REGIONAL 啟用，且實例成本大約翻倍。
同步式待機拓撲
底層上，Cloud SQL 會在一個可用區建立主要實例，並在同區域的另一個可用區建立同步式 standby。寫入必須在兩個節點都 commit 之後才會回 ACK 給 client，這也是 99.95% 單實例 SLA 的依據。Standby 對 client 是隱形的；它不接受獨立連線，你也不能用它來分擔讀取——分擔讀取是讀取副本的工作。
自動故障轉移觸發條件
當主要實例的健康檢查連續失敗約 60 秒，Cloud SQL 會啟動 failover。Standby 被升格，浮動 IP / DNS 主機名稱被切換，現有 TCP 連線被中斷。MySQL 與 PostgreSQL 的 failover 通常在 60-120 秒內完成；SQL Server 時間相近。應用程式必須自行重新連線——並沒有 transparent connection migration。
為演練手動觸發 Failover
可以用 gcloud sql instances failover INSTANCE 強制 failover。受監管的工作負載每個月會跑一次當作 chaos drill，讓營運團隊在凌晨 3 點的事故發生前就熟悉 runbook。Failover 會被計入 mysql.failoverCount 指標，可用於告警 production 是否異常發生 failover。
Cloud SQL HA 僅限同區域——同步式 standby 一定與主要實例在同一個 region。若要承受整個 region 失效，你需要一個跨區域的讀取副本以便緊急升格，並接受非同步複寫延遲（通常數秒到數分鐘）的 RTO。詳見 Cloud SQL high availability。
Cloud SQL Auth Proxy 與 IAM 資料庫驗證
從 Cloud Run、GKE、App Engine 或開發者筆電安全連線到資料庫，是 PCD 考試中 Cloud SQL 題目最常出現的範圍。
Cloud SQL Auth Proxy 運作原理
Cloud SQL Auth Proxy 是一個小型 binary（或位於 gcr.io/cloud-sql-connectors/cloud-sql-proxy 的 sidecar container），它會用 Application Default Credentials 向 Cloud SQL Admin API 認證、取得短期 TLS 憑證，然後在本機開出 TCP socket 或 Unix domain socket。應用程式連到 127.0.0.1:5432（PostgreSQL）或 /cloudsql/PROJECT:REGION:INSTANCE（Unix domain socket），完全不需要 IP allowlist、不需要長期靜態憑證（資料庫帳號密碼除外），實例本身也可以完全不開公開 IP。
所需 IAM 角色
執行 proxy 的服務帳戶需要 roles/cloudsql.client（基本權限），或 roles/cloudsql.instanceUser（用於 IAM 資料庫驗證）。單一專案可在專案層級授權；共用專案則建議使用 conditional IAM bindings 限定到特定實例名稱。
IAM 資料庫驗證
不必把密碼存放在 Secret Manager，可在實例上啟用 cloudsql.iam_authentication=on，並把 roles/cloudsql.instanceUser 授予某個服務帳戶。Proxy 會把 OAuth access token 當作資料庫密碼遞交，由資料庫向 IAM 驗證。優點包含：不必輪替密碼、Cloud Audit Logs 留下完整稽核軌跡，撤銷存取只是一次 IAM binding 變更。MySQL 8 與 PostgreSQL 支援。
Cloud SQL Auth Proxy 作為 Cloud Run sidecar
在 Cloud Run 上的現代寫法，要嘛是在部署時加 --add-cloudsql-instances（Cloud Run 會幫你跑 proxy），要嘛是把 proxy 以 sidecar 形式放入多容器 revision。Sidecar 模式給你完整的版本控制、結構化日誌與 IAM 驗證旗標的掌握。
讀取副本：同區域與跨區域
讀取副本能分擔讀取流量、以一致性為代價支援讀後寫，並可同時兼任災難復原資源。
非同步複寫模型
Cloud SQL 讀取副本會以非同步方式接收主要實例的 binary log（MySQL）、WAL（PostgreSQL）或 transaction log（SQL Server）。健康狀態下副本與主要實例的延遲在毫秒級，但在寫入尖峰或副本端 CPU 飽和時可能漂移到數分鐘。Cloud Monitoring 中的 replication_lag 指標必須持續監控。
同區域讀取副本
使用 gcloud sql instances create REPLICA --master-instance-name=PRIMARY --tier=... 在主要實例同 region 的任一 zone 建立。使用場景：擴充讀取量大的儀表板、把分析查詢與交易流量隔離、為 BI 工具提供讀取來源而不阻塞寫入。
跨區域讀取副本
只要在指定 --region 時填不同 region，就會建立跨區域副本，可同時當作 DR 機制。當 region 失效時可以升格（gcloud sql instances promote-replica）——一旦升格，它就變成獨立的主要實例，無法再回去當副本。一般 RTO 是偵測、決策、升格的總時間（人工流程通常 15-30 分鐘）。
副本的限制
副本本身預設沒有 HA standby，除非你明確開啟。MySQL 5.7 的副本無法再建立自己的副本。Schema 變更必須在主要實例上做，並透過複寫流到副本；副本上的 DDL 會被拒絕。
AlloyDB 與 columnar engine
對於同時混合 OLTP 與大量分析掃描的 PostgreSQL 工作負載，AlloyDB for PostgreSQL 是超越 Cloud SQL for PostgreSQL 的升級路徑。
混合式交易/分析架構
AlloyDB 把運算層與儲存層拆開，透過具備智慧的儲存層處理寫入複寫，並引入機器學習驅動的索引建議。官方行銷數字包含「交易型工作負載比原生 PostgreSQL 快 4 倍」以及「分析型查詢最高快 100 倍」——這些數字來自下一個重點。
Columnar engine
AlloyDB 的 columnar engine 會在 row store 之外，為經常被掃描的表格自動維護一份記憶體中的 columnar 表示。Optimiser 會透明地把分析查詢（大範圍 WHERE、GROUP BY、聚合查詢）導向 columnar 副本。透過 google_columnar_engine.enabled=on 啟用；交由 auto-recommend 功能根據工作負載遙測資料挑選要實體化的欄位。
AlloyDB 何時勝過 Cloud SQL
如果團隊已經確定使用 PostgreSQL、查詢經常要掃過數百萬列做聚合，且不想為了 HTAP 而維護雙堆疊（Cloud SQL 加上 BigQuery），AlloyDB 就是正確選擇。若只是普通 CRUD 與點查詢，純 Cloud SQL 較便宜。
當 Cloud SQL for PostgreSQL 的工作負載開始混合 10 ms 等級的點查詢與秒級的分析掃描在同一張表上時，AlloyDB 就是合理的升級對象。Columnar engine 可以消除「複寫到 BigQuery 做臨時分析」這種雙堆疊模式。詳見 AlloyDB columnar engine。
Cloud Spanner Regional 與 Multi-Region 配置
Spanner 實例由 instance-config 決定，這個設定會直接影響複寫拓撲與 SLA。
Regional 配置（99.99% SLA）
Regional 配置（例如 regional-us-central1、regional-asia-east1）會在單一 region 內、跨三個 zone 放三個 voting replica。讀取與寫入都在當地服務；SLA 為月度 99.99% 可用性。價格約為 multi-region 的一半，當所有讀取者都在同一個 region 時是預設選擇。
Multi-Region 配置（99.999% SLA）
Multi-region 配置（例如 nam-eur-asia1、nam6、eur3）會在三個 region 放置 voting replica，並加上一個以上的 read-only replica。它透過 Paxos 跨 region commit 寫入，提供 99.999% 月度 SLA——一年僅允許約 5 分 15 秒的停機時間。北美客戶選 nam6、歐洲資料居留需求選 eur3、真正全球性的工作負載選 nam-eur-asia1。
Read-Only 與 Witness Replica
Multi-region 配置內含 read-only replica，可以提供無需 Paxos 來回的 stale read；以及 witness replica，它在 Paxos 中投票但不存放表格資料——存在的目的是當整個 region 中斷時打破平手。
運算容量：Node 與 Processing Unit
Spanner 容量以 processing units（PU）販售；1,000 PU 等於 1 個 node。粗略而言每個 node 提供約 10,000 QPS 讀取、2,000 QPS 寫入與 2 TB 儲存。容量可在不停機、不改 schema 的情況下線上調整。
Spanner 的 99.999% multi-region SLA 只適用於 multi-region instance configurations（例如 nam-eur-asia1）。Regional 配置的 SLA 是 99.99%。若只是因為「multi-region 聽起來比較安全」就選錯，每月帳單可能變成原本的四倍，卻換來一個你並不需要的 SLA。詳見 Spanner instance configurations。
Spanner Schema 設計：Interleaved Tables 與 STORING Index
Spanner schema 設計由兩個實體儲存佈局決定主導：相關列如何共置，以及索引在讀取路徑上能否自給自足。
Interleaved Tables
Interleaved table 會把子列實體存放在父列所在的 split 內部。透過 INTERLEAVE IN PARENT Parent ON DELETE CASCADE 宣告之後，OrderItems 表會把同一個 OrderId 的每一筆 OrderItem 放在與其父 Order 同一個磁碟頁面上。效益顯著：Orders join OrderItems 變成本機掃描而不是網路 round trip。
避免熱點
千萬不要用單調遞增的欄位（時間戳記、序號、auto-increment）當主鍵的領頭欄——每一筆新列都會命中同一個 split，讓單一節點變成瓶頸。改用 UUID、位元反轉序號（BIT_REVERSE(seq, true)），或對 tenant id 做 hash 後放在主鍵領頭欄。
Secondary Index 與 STORING 子句
Spanner 的 secondary index 底層本身也是一張表。預設情況下，索引只涵蓋索引欄位加上主鍵。需要其他欄位的查詢必須回到 base table 再做 join。STORING 子句允許把額外欄位直接放入索引條目，省去回查：CREATE INDEX OrdersByCustomer ON Orders(CustomerId) STORING (TotalAmount, Status)。儲存成本上升，但讀取延遲下降。
NULL_FILTERED Index
對於大多數列為 NULL 的稀疏欄位，使用 CREATE NULL_FILTERED INDEX ——索引只儲存該欄位非 NULL 的列，可省下大量儲存空間。常見於軟刪除旗標、選用性外鍵或功能開關欄位。
Spanner 的常見反模式是建立 secondary index 卻不加 STORING 子句，然後抱怨讀取延遲過高。每次讀取都變成「索引探測 + base table 回查」，IO 直接翻倍。一定要為熱點查詢回傳的欄位加上 STORING。詳見 Spanner secondary indexes。
透過 BigQuery External Dataset 查詢 Spanner
Spanner 是為營運性工作負載打造的，但分析團隊希望能用 SQL 存取而不必先架一條 CDC pipeline。BigQuery external dataset 就是這座橋樑。
External Dataset 機制
在 BigQuery 中建立一個指向 Spanner 資料庫的 external dataset：bq mk --connection ... 之後執行 CREATE EXTERNAL TABLE 引用該連線。對 external dataset 的查詢屬於聯邦查詢——BigQuery SQL 引擎會把 filter 與 projection 下推到 Spanner，透過 Cloud Spanner 連線執行讀取，並把結果回傳給分析師，使用體驗就像查詢原生 BigQuery table。
使用場景
在單一 SQL 查詢內混合交易性的 Spanner 資料與 BigQuery 分析表。在不安排 copy job 的情況下建立操作資料的即時儀表板。對於低流量的分析需求，可以省去專屬 Datastream-to-BigQuery pipeline 的延遲、成本與營運負擔。
限制與成本
External dataset 查詢會吃 Spanner 實例的 CPU 預算——大量分析掃描會排擠交易流量。對於高流量的分析需求，建議改用下方介紹的 change streams 做專屬 CDC 進 BigQuery，並把 external dataset 路徑保留給偶發性的 ad hoc join。
Cloud Spanner Change Streams
Change streams 會擷取被監看資料表上的每一次 insert、update、delete，並以可查詢的串流形式對外提供。
定義 Change Stream
DDL：CREATE CHANGE STREAM AllOrdersStream FOR Orders, OrderItems OPTIONS (retention_period = '7d');。Spanner 會在內部 change record store 追蹤這些資料表的變動，並依設定的保留期間（1 至 7 天）保存。
透過 Dataflow Connector 消費
官方建議的消費方式是使用 Apache Beam SpannerIO connector，跑在 Dataflow 上。Connector 讀取 change records、把它們交給你的 pipeline，並讓你把變更 sink 到 BigQuery、Pub/Sub、Cloud Storage 或另一個 Spanner 實例。Google 也提供 Spanner → BigQuery 的官方 Dataflow template。
常見使用場景
為了分析在 BigQuery 內維護一份接近即時的 Spanner 鏡像。將稽核日誌餵入 SIEM。把快取失效訊息推送到 Memorystore。當特定列變動時透過 Pub/Sub 觸發下游工作流。
與 Cloud SQL CDC 的差異
Cloud SQL 透過 binary log（MySQL）或 logical replication slot（PostgreSQL）對外提供變更，可由 Datastream 消費後落地到 BigQuery 或 Cloud Storage。觀念相同，實作面不同——Spanner change streams 是 DDL 一等公民，Cloud SQL CDC 則是 Datastream 層級的設定。
Spanner 備份與 Point-in-Time Recovery
Spanner 的備份故事在概念上與 Cloud SQL 不同，因為它的儲存層原本就保留多版本資料。
一次性與排程備份
gcloud spanner backups create 會在某個指定時間點建立資料庫的一致性備份。備份存放在同一個實例，最長可保留一年。可用 backup schedule（full 或 incremental）自動執行每小時、每日或每週快照，不必自行寫程式。
Point-in-Time Recovery
每個 Spanner 資料庫都有 version_retention_period（預設 1 小時，最高可調到 7 天）。在這個視窗內，任何讀取都可以指定 READ_TIMESTAMP 或 MIN_READ_TIMESTAMP，取得該時刻的一致性視圖——無需執行 restore。若要從誤刪事件中復原，只要在較早的時間戳把受影響的列複製出來，寫入一張救援表即可。
Restore 備份
Restore 會建立一個全新資料庫；不能直接 restore 進既有資料庫。Restore 耗時依資料量為數分鐘到數小時，期間與同實例其他資料庫的流量並行不衝突。
備份加密
備份會繼承資料庫的 CMEK 設定。跨區域備份複製（在支援的場景中）需要目標 region 對相同 key 具備存取權，這在資料居留稽核中是重要細節。
Cloud SQL 維護視窗與 Denylist Days
Cloud SQL 的維護無法避免——Google 必須為底層作業系統、資料庫引擎與安全性修補打補丁——但你可以掌控何時發生。
設定維護視窗
透過 gcloud sql instances patch INSTANCE --maintenance-window-day=SUN --maintenance-window-hour=3 設定每週四小時的維護視窗。選擇符合租戶時區的低流量時段。在視窗內的維護會造成主要實例一次短暫重啟（單可用區）或一次 failover 風格重啟（HA）。
維護 release channel
可以選 production（預設，獲得在 preview 通道驗證過後的穩定更新）或 preview（提前體驗，適合 dev/test）。正式工作負載通常維持 production，除非確實需要某個特定 patch。
Deny Maintenance Period（Denylist Days）
對於變更凍結事件——黑色星期五、季末、事故處置中——可以宣告最長 90 天 的 deny maintenance period，在這段期間 Google 不會執行任何維護：gcloud sql instances patch INSTANCE --deny-maintenance-period-start-date=2026-11-25 --deny-maintenance-period-end-date=2026-12-02 --deny-maintenance-period-time=00:00:00。一年中可以堆疊多個 period（總計上限 90 天）以涵蓋所有 code freeze 視窗。
維護通知
Cloud SQL 會在排程事件前一週寄送維護通知到專案的通知電子郵件，並寫入 Cloud Monitoring 的 cloudsql.googleapis.com/database/maintenance 日誌。把它接到 PagerDuty，讓 on-call 工程師在重啟發生前就掌握資訊。
Cloud SQL 維護：每週 4 小時視窗，可設定 day/hour，並支援單次最多 90 天、年度總上限 90 天的 deny maintenance period 用於變更凍結。Spanner 沒有對應機制——它的 rolling update 是隱形的，因為 multi-region quorum 可以容忍每個 replica 重啟而不會中斷服務。詳見 Cloud SQL maintenance overview。
在 Cloud SQL、AlloyDB 與 Spanner 之間選擇
這是考試與真實架構評審都適用的決策框架。
何時選 Cloud SQL
需要 MySQL、PostgreSQL 或 SQL Server 相容性；工作負載落在單一 region 內；資料量在 64 TB 以下；寫入吞吐量峰值約在 4,000 QPS 以下。這涵蓋了絕大多數 SaaS 後端、內部工具與現代化的舊系統。
何時選 AlloyDB
已經確定 PostgreSQL；工作負載在同一張表上混合 OLTP 與分析掃描；想避免維護獨立的分析堆疊。AlloyDB 對於透過 pgvector 擴充的向量工作負載也具優勢，並且最大 128 TB 的儲存上限，對於 Cloud SQL 儲存天花板已成問題的大型 PostgreSQL 資料庫是合理升級。
何時選 Spanner
需要水平寫入擴充（持續數萬 QPS）、全球強一致性、99.999% multi-region SLA，或正在打造資料庫本身必須超越任何單一 region 壽命的系統。金融帳本、全球庫存、超大規模多租戶 SaaS，以及目前以「分片 MySQL + 自建一致性」運作的應用，都是教科書級別的 Spanner 工作負載。
考試技巧與常見陷阱
PCD 考試很喜歡測試這些服務的邊界。
陷阱：把 HA 當成 DR
Cloud SQL HA 只能對抗單 region 內的可用區失效。它不是 DR。Region 級故障會讓主要實例與 standby 都失效。DR 的工具是跨區域讀取副本與升格流程。
陷阱：替部落格選 Spanner
Spanner 最低支出（一個 1,000 PU 實例 24 小時運作）每月就是數百美金——對於 QPS 不到數千的工作負載是嚴重 overkill。在需求未明確要求 Spanner 之前，預設使用 Cloud SQL。
陷阱：索引忘記加 STORING
Spanner secondary index 若沒有 STORING，所有需要索引鍵之外欄位的查詢 IO 都會翻倍。記得先把熱點讀取路徑建模出來，再用 STORING 涵蓋這些查詢會回傳的欄位。
技巧：及早處理連線池
Cloud Run 可以擴充到上千個實例，每個實例都會開資料庫連線。Cloud SQL 搭配 PgBouncer（sidecar 或集中代管）或 cloud-sql-python-connector 內建的 pooling。Spanner 使用 gRPC session 並具備內建 pooling——由 client library 自動處理。
技巧：version_retention_period 一次設好
把 Spanner 資料庫的 version_retention_period 從 1 小時調到 7 天會立即生效，免費換來一週的 PITR 視窗。正式環境資料庫建議第一天就設好。
常見問題（FAQs）
Q1：Cloud SQL HA 副本可以跨 region 嗎？
A1：不行。HA standby 永遠位於同 region 的另一個 zone。若要跨 region 韌性，建立跨區域讀取副本，在 region 失效時將其升格。升格是不可逆的——副本會成為新的主要實例。
Q2：Spanner 支援 PostgreSQL 語法嗎？
A2：支援。Spanner 提供 PostgreSQL interface dialect，與原生 GoogleSQL 並存。Dialect 在資料庫建立時選擇，事後無法切換。PostgreSQL dialect 支援大多數 pgwire client、ORM 與標準 SQL 功能，但並非 100% 與原生 PostgreSQL 相容——遷移前先確認所需擴充與函式是否支援。
Q3：Cloud SQL Auth Proxy 一定要搭配 IAM 驗證嗎？
A3：不一定。Proxy 本身透過 IAM 對 Cloud SQL Admin API 認證，但實際資料庫登入預設仍使用資料庫的帳號密碼。啟用 cloudsql.iam_authentication=on 並授予 roles/cloudsql.instanceUser，proxy 才會把 OAuth token 當作資料庫密碼遞交，從此不必管理密碼。
Q4：Spanner change stream 最長可保留多久？
A4：7 天。透過 CREATE CHANGE STREAM DDL 的 OPTIONS (retention_period = '7d') 設定。超過保留期間的紀錄會被 garbage collection，無法再重播。
Q5：Cloud SQL deny maintenance period 最長多久？
A5：單一 period 最長 90 天，且全年可堆疊多個 period（年度總上限 90 天）。適用於黑色星期五、會計年度結算、法規稽核或任何不可預期重啟代價過高的視窗。
Q6：AlloyDB 與 Cloud SQL for PostgreSQL wire 協定相容嗎？
A6：兩者都使用 PostgreSQL wire protocol，相同的 driver（psycopg2、pgx、JDBC）都可用。AlloyDB 對應某個特定 PostgreSQL 主版本，且提供 Cloud SQL 沒有的 Google 專屬擴充（例如 google_columnar_engine）。雙向遷移通常可以透過 pg_dump / pg_restore 加上擴充清單檢核完成。