如果要求 LLM 針對正式環境資料庫寫 SQL，寫出來的結構通常看起來正確，但可能引用了不存在的資料表、半年前就改名的欄位，或憑空捏造 JOIN 條件。這會導致查詢直接失敗，甚至面臨更糟情況：指令成功執行，卻回傳了錯誤的數據。

為了解決 LLM 亂寫 SQL 的問題，目前的作法是透過 MCP，利用 PostgreSQL 的原生架構來確保查詢的準確性。

技術背景與初步嘗試

在 2024 年初還沒有 MCP 或 AI Agent 的概念。為了讓聊天機器人能串接 API 取得即時資料，當時通常採用比較拼湊的流程：

1. 把 OpenAPI spec 餵給 LLM。
2. 要求 LLM 只能回傳 curl 指令。
3. 透過 Go 函式去執行這個 curl 指令。
4. 把執行的結果再丟回給 LLM，讓它轉換成一般人看得懂的回答。

User: "What's the CPU usage and total DB connections right now?"
 -> LLM + API Spec -> curl -X GET https://portal.curiousone.in/api/v1/metrics?names=cpu,db_conn
 -> execute() -> { cpu: 72%, conn: 84 }
 -> LLM: "CPU is at 72% and there are 84 active DB connections."

這做法雖然可行，但完全無法擴充。每增加一個新資料來源，就得寫一套新的 parser；而且 Prompt 工程脆弱，必須針對每一種 spec 或 schema 重新調整。

後來也發現不少團隊在開發這類應用時，也都面臨一模一樣的挑戰。直到 Anthropic 釋出 MCP作為開放標準，問題才得到解決。

為何 LLM 總是寫錯 SQL？

LLM 其實看得懂 SQL 語法，也能寫出包含 CTE、子查詢的複雜指令。但它無法得知資料表名稱、欄位名稱或關聯性，只能單純根據訓練資料的盲猜。

對比如下：

LLM 猜測資料表叫 users，但實際上是 app_customers；猜測欄位叫 name，但實際上是 full_name；猜測外鍵（Foreign Key）是 o.user_id，但實際上是 o.customer_id。它的每一次猜測聽起來都很合理，但結果全都是錯的。

上下文斷層（Context Gap）

這類錯誤歸根究底，都是因為缺乏上下文所導致的：

解決這個問題的關鍵並不是去寫更好的 Prompt，而是要在 LLM 進行查詢的當下，直接讓它讀取到真實的資料庫 Schema。

解決方案：Model Context Protocol (MCP)

MCP 是一種開放標準，主要用來連接 AI 模型與外部資料來源和工具。

在技術架構上的核心特點是：單一 MCP 用戶端可以連接多個 MCP 伺服器，而每個伺服器各自封裝不同的資料來源。以 Postgres 運作來說，代表同一個 AI 助理可以同時存取多個資料來源，例如：

                    ┌─ Postgres MCP Server ──→ PostgreSQL (live schema & queries)
                    │
MCP Client ─────────┼─ Filesystem MCP Server ─→ PG Logs (log file analysis)
(Claude, IDEs)      │
                    └─ Prometheus MCP Server ─→ Telemetry (metrics & alerting data)

在這個架構中，Client 端就是 AI 應用程式，而每個 Server 端則提供工具供 LLM 呼叫，彼此透過 stdio 或 SSE 傳輸協定來跑 JSON-RPC 2.0。LLM 會根據使用者的問題，自己決定要呼叫哪一個 Server。

舉例來說：如果詢問的是 Schema 相關問題，它會去找 Postgres MCP；但如果問的是「為什麼昨天晚上資料庫變慢？」，就可能同時呼叫 Filesystem MCP（去看 Log 紀錄）和 Prometheus MCP（去抓指標數據）。

核心組成要素

在 MCP 的三種基本元件中，資料庫應用最核心的是 Tools：

• Tools： 這是供 LLM 呼叫的函式，會直接回傳即時結果。例如 execute_sql、list_schemas、list_objects 等，這類工具回傳的是最新狀態，而不是過期的快照。
• Resources： 透過 URI 提供的唯讀靜態資料。如果把資料庫 Schema 當成這種靜態資源發布，資訊很快就會過期，因此並不適合用來處理動態的資料庫元資料。
• Prompts： 封裝了上下文與指令的重複使用範本。雖然實用，但在資料庫的操作中屬於輔助角色。

PostgreSQL 結合 MCP：pg-airman-mcp

pg-airman-mcp 是一款針對 PostgreSQL 設計的 MCP 伺服器，能讓 LLM 即時存取資料庫的結構與資料。以下是它所提供的核心工具：

查詢流程

當使用者詢問「幫我列出營收前五名的客戶」時，LLM 不再用盲猜的方式，而是依序執行以下步驟：

1. 呼叫 list_schemas： 確認目前有哪些可用的 Schema。
2. 呼叫 list_objects： 取得真實的資料表與檢視表（View）名稱。
3. 呼叫 get_object_details： 掌握欄位、資料型態、條件約束與索引。
4. 呼叫 explain_query： 驗證執行計畫並檢查效能。
5. 呼叫 execute_sql： 在具備存取控制與安全解析的機制下執行查詢。

到了第 3 步，LLM 已經明確知道資料表叫 app_customers、欄位是 full_name，且外鍵是 customer_id。整個過程完全不需要任何猜測。

透過 pg_catalog 讓 Postgres 自行維護元資料

這套架構最核心的優勢，在於 Postgres 本身就已經完整記錄了所有需要的元資料。MCP 伺服器完全不需要依賴外部的設定檔、Schema 傾印檔案，或是常常忘記更新的系統文件。它只需要直接查詢 Postgres 的系統目錄：

• pg_class：記錄所有的資料表、檢視表與序列。
• pg_attribute：記錄欄位名稱與資料型態。
• pg_constraint：記錄主鍵（PK）、外鍵（FK）與 CHECK 條件約束。
• pg_index：記錄用於查詢最佳化的索引資訊。
• pg_namespace：記錄 Schema。
• pg_description：記錄 COMMENT ON 的註解內容（這能直接當作 LLM 的文件說明）。

在底層運作上，MCP 伺服器就是透過執行這類的查詢來獲取即時資訊：

-- list_schemas
SELECT
  schema_name, schema_owner,
  CASE
    WHEN schema_name LIKE 'pg_%' THEN 'System Schema'
    WHEN schema_name = 'information_schema' THEN 'System Info Schema'
    ELSE 'User Schema'
  END AS schema_type
FROM information_schema.schemata
ORDER BY schema_type, schema_name;
-- list_objects
SELECT
  CASE c.relkind
    WHEN 'r' THEN 'table'
    WHEN 'v' THEN 'view'
  END AS object_type,
  n.nspname AS table_schema,
  c.relname AS table_name,
  d.description AS comment
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_catalog.pg_description d
  ON d.objoid = c.oid AND d.objsubid = 0
WHERE n.nspname = $1 AND c.relkind IN ('r','v')
ORDER BY c.relname;
-- get_object_details
SELECT
  column_name, data_type,
  is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = $1
  AND table_name = $2
ORDER BY ordinal_position;

這些查詢是直接針對線上資料庫即時執行。不論欄位是新增、改名或刪除，MCP 伺服器都能在第一時間同步反應最新狀態。

透過 EXPLAIN 最佳化查詢

掌握正確的資料表與欄位是第一步，接下來還必須確保寫出來的查詢具備良好的執行效率。

透過 explain_query 工具，系統會把 LLM 生成的 SQL 先丟給 Postgres 的查詢規劃器（Query Planner）進行評估。如果 EXPLAIN 的結果顯示該執行計畫不夠理想，LLM 就能在幾毫秒內、在使用者完全沒有察覺的情況下，重寫並修正語法，才正式執行。

例如，以下是 LLM 的第一次嘗試：

SELECT c.full_name, SUM(o.total_price)
FROM   app_customers c
JOIN   customer_orders o ON c.id = o.customer_id
GROUP BY c.full_name
ORDER BY total DESC;

透過 EXPLAIN 的分析發現：這段查詢會對約 50 萬筆資料進行全表掃描，且沒有設定日期篩選（導致掃描了歷史至今的所有訂單），執行時間長達近 3,000 毫秒。

LLM 讀取 EXPLAIN 的輸出結果後，便會主動重寫 SQL：

SELECT c.full_name, SUM(o.total_price)
FROM   app_customers c
JOIN   customer_orders o ON c.id = o.customer_id
WHERE  o.created_at >= NOW() - INTERVAL '90 days'
GROUP BY c.id, c.full_name
ORDER BY total DESC
LIMIT 10;

優化後轉為索引掃描，掃描筆數縮減至約 3,000 筆，執行時間縮短到 20 毫秒，速度提升了約 150 倍。

在這個過程中，LLM 透過分析 EXPLAIN 執行計畫的結果，主動加上了日期篩選條件、修正了 GROUP BY（納入 c.id 以確保資料正確性），並加上了 LIMIT。這完全是基於即時的執行計畫評估，而不是死背硬記的最佳化規則。

安全防護機制（Guardrails）

要讓 LLM 能夠存取資料庫，必須部署多層安全機制。以下是推薦的標準配置方法：

首先，從配置唯讀帳號開始，並且只授予 GRANT SELECT 權限。這樣一來，即使 LLM 生成了 DROP TABLE 這類的指令，Postgres 也會在資料庫引擎層級直接拒絕執行。

CREATE ROLE mcp_reader LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE mydb TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;

針對多租戶架構的資料庫，可以啟用資料列級安全性（Row-Level Security, RLS）。這能直接在 Postgres 引擎層級強制隔離資料，即使面臨 SQL 注入（SQL Injection）攻擊也無法繞過這層防禦。

ALTER TABLE customer_orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON customer_orders
  FOR SELECT USING (
    tenant_id = current_setting('app.tenant_id')::int
  );

execute_sql 工具本身也提供了可自訂的存取控制、強制唯讀模式、安全的 SQL 解析機制，以及針對長時間異常查詢的 statement_timeout 限制。系統也會為每筆查詢記錄包含上下文的 Log，並強制執行速率限制。

這些安全機制並非選配，而是將 MCP 應用在任何真實資料庫時都必須具備的基本防線。

開始使用 pg-airman-mcp

只花幾分鐘，就能完成 pg-airman-mcp 的設定。請將以下內容新增到 MCP 用戶端設定檔中：

{
  "mcpServers": {
    "postgres": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "AIRMAN_MCP_DATABASE_URL",
        "enterprisedb/pg-airman-mcp",
        "--access-mode=unrestricted"
      ],
      "env": {
        "AIRMAN_MCP_DATABASE_URL": "postgresql://mcp_reader:pass@localhost:5432/mydb"
      }
    }
  }
}

在正式環境中，請使用 --access-mode=restricted（受限模式）。完成後重新啟動你的 MCP 用戶端，接下來就能自由進行任何查詢了。（更多設定説明）

更棘手的問題：悄悄出錯的查詢

Schema 探索機制只能解決表面上的明顯錯誤，例如寫錯資料表、漏掉欄位或語法錯誤的 JOIN。但還有另一個問題是它無法解決的。

當你詢問 LLM：「我們這個月的營收是多少？」時，SQL 順利執行了，跑出來的數據看起來也非常合理。但實際上，那個數字是錯的。

-- What the LLM generates
SELECT SUM(o.total_price)
FROM   customer_orders o
WHERE  o.created_at >= '2026-04-01'

這段查詢能正常執行，也會回傳一個數字。但這個數字卻把「已取消的訂單」、「已退款的訂單」，以及 is_deleted = true 的軟刪除（Soft-deleted）資料全都算進去了。

正確的查詢應該是：

-- What the query should be
SELECT SUM(o.total_price)
FROM   customer_orders o
WHERE  o.created_at >= '2026-04-01'
  AND  o.status != 'cancelled'
  AND  o.is_deleted = false
  AND  o.is_refunded = false

這就是所謂的「內部潛規則」。這些邏輯只存在於開發人員的腦袋裡，根本沒有寫進 Schema。不論再怎麼去查 pg_catalog，系統目錄也絕對不會告訴你：只要查詢 customer_orders，就必須一律加上 is_deleted = false 這個篩選條件。

解決方案：利用 FastMCP 客製化 MCP 伺服器

解決這個問題的方法，是將業務邏輯直接封裝進 MCP 工具中。讓 LLM 直接呼叫一個早已寫好規則的工具，而不是讓它從頭開始盲寫 SQL。

from fastmcp import FastMCP
import psycopg2

mcp = FastMCP("revenue-server")

@mcp.tool()
def get_monthly_revenue(month: str, year: int) -> dict:
    """Get actual revenue excluding cancelled,
    refunded, and soft-deleted orders."""
    conn = psycopg2.connect(DB_URL)
    cur = conn.cursor()
    cur.execute("""
        SELECT SUM(o.total_price)
        FROM   customer_orders o
        WHERE  DATE_TRUNC('month', o.created_at)
               = DATE_TRUNC('month', %s::date)
        AND    o.status != 'cancelled'
        AND    o.is_deleted = false
        AND    o.is_refunded = false
    """, [f"{year}-{month}-01"])
    result = cur.fetchone()
    return {"revenue": float(result[0] or 0)}

if __name__ == "__main__":
    mcp.run()

透過 Python 的 Docstring（文件字串），我們可以直接告訴 LLM 這個工具的功能；而真實的業務規則則已經寫死在函式實作中。這樣一來，當 LLM 遇到營收相關的問題時，它會直接呼叫 get_monthly_revenue，而不是自己瞎猜語法。

混合模式

在實際應用中，這兩種做法缺一不可，必須搭配使用。

• Postgres MCP 負責結構層： 處理 Schema、資料表、欄位與外鍵，告訴 LLM 資料庫裡「存在哪些東西」，防止 LLM 產生結構上的幻覺（Structural Hallucinations）。
• 客製化 MCP 負責邏輯層： 封裝了業務邏輯、篩選條件、合規規則與團隊內部的潛規則，告訴 LLM 這些資料「代表什麼意思」，杜絕語義上的幻覺（Semantic Hallucinations）。

實際運作時的互補效果：

• 面對欄位命名古怪的舊系統？由 Postgres MCP 即時探索結構。
• 面對複雜的狀態旗標或潛規則 JOIN？由客製化 MCP 內建規則。

為什麼不直接用其他方法？

要把資料庫的 Context 提供給 LLM，其實還有其他幾種做法。以下是它們與 MCP 的對比：

• 直接貼 Schema： 這種做法玩玩小專案還可以，一旦資料表結構發生變化就直接破功。
• RAG 模式： 適合用來對文件進行語義搜尋，但面對需要百分之百精準的「結構化元資料」時，表現並不理想。
• 微調模型： 等於是把 Schema 的硬編碼進模型裡，只要資料庫一版更，模型懂的知識就過期了。
• MCP 機制： 每次遇到提問，都是直接去查當下最即時的線上資料庫。

核心結論

• 精準的 Prompt 無法解決幻覺： LLM 會寫出錯誤的 SQL，核心原因在於它們缺乏資料庫的即時上下文，這一點光靠優化提示詞是無法根治的。
• MCP 是橋接的關鍵： MCP 是一個將 LLM 連接到外部資料的開放協定。pg-airman-mcp 正是利用了 pg_catalog 與 information_schema，將 Postgres 原生的「自我認知」直接轉化為 LLM 的背景知識。
• 客製化 MCP 補足盲點： 透過 FastMCP 建立的客製化 MCP 伺服器，能進一步將業務邏輯與團隊內部的「潛規則」封裝起來，解決單靠結構探索無法得知的業務語義。
• 雙劍合璧才是正解： 運用 Postgres MCP 搞定結構，加上 客製化 MCP 搞定語義 —— 這種混合模式才是讓 LLM 真正落地、搞定企業級複雜資料庫的終極方案。

本文翻譯自：Building Real-Time, Data-Aware Intelligence with Postgres and the Model Context Protocol

參考資料：

• Model Context Protocol Specification
• pg-airman-mcp
• PostgreSQL System Catalogs

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

針對這個挑戰，EDB 推出新一代 EDB Postgres AI Factory，協助企業在完全掌控資料的前提下，落實生成式 AI（GenAI）的推論應用。市場趨勢顯示，領先企業已不再將 AI 視為單一專案，而是將其納入基礎架構的一環。

推薦閲讀：EDB Postgres® AI 2026 第一季新功能亮點

成功關鍵：資料主權與架構

根據一項針對全球 2,050 位企業領袖的調查，雖然 95% 企業計畫在三年內建立自有的 AI 與資料平台，但僅 13% 能真正產生效益。他們的 ROI 是同業的 5 倍，在生產環境中部署的 AI Agent 數量也是兩倍以上。其優勢在於對「資料主權」的掌控：能完全管理資料的儲存、存取方式與 AI 運作邏輯，同時解決安全性、合規與規模化擴展的難題，而不必在技術間權衡取捨。

EDB Postgres AI 是為了解決這些挑戰而設計，新一代 AI Factory 則進一步強化了這項能力。

Gartner 報告指出，具備生成式 AI 功能的資料庫管理系統（DBMS）支出預計到 2028 年將成長三倍，且超過 75% 的企業將 AI-ready data 列為首要投資項目。Gartner 將 EDB 列為企業級 AI Agent 的代表性供應商，並強調資料庫在架構中扮演的三大關鍵角色：Agent 記憶（Memory）、知識來源（Knowledge source）與任務執行（Task execution）。目前的挑戰在於：如何在不產生技術債的情況下，滿足開發需求並將應用推向生產環境。

AI Agent 適用場景與分層模型

AI Agent 能處理自動化網路監控、多步驟客服流程及即時營運情資，其商業價值在於處理開放式任務、模糊輸入與跨系統調度。

例如：在處理資料庫效能問題時，Agent 能在秒級內分析慢查詢日誌、檢查鎖定表並提供分析假設，這類高價值的推理能力是其優勢。

然而，針對具備明確邏輯的任務，如系統擴展、故障轉移或組態變更，過度使用 Agent 反而會增加複雜度與風險。這類任務應採用確定性的策略引擎，而非機率性的 AI 模型，以避免合規風險與難以除錯的行為。

成熟的技術架構不應是「全 Agent 化」，而是採用分層模型：

• Agent 層：分析、建議與綜合資訊
• 策略引擎層：驗證與最終決策
• 執行層：具體行動

此架構能確保在需要的地方發揮智慧，在關鍵的地方保持掌控。企業需要的解決方案應能輕鬆開發基於真實資料的 Agent，而非僅能在測試環境運作的原型，並彈性地將 Agent 置於合適的架構層級中。

日本電信商 NTT East 便採用 EDB Postgres AI Factory，在完全私有的環境中部署用於網路維運的 AI Agent，實現自動化偵測與問題回應。這證明了技術信心不僅來自模型，更來自底層的基礎架構。

Agent Studio：視覺化開發與整合

EDB AI Factory 最顯著的演進是重塑了 Agent Studio。它採用 Langflow 作為視覺化整合開發環境（IDE），並基於產業標準的 LangChain 生態系建構而成。

許多企業的 AI 計畫在從概念驗證（PoC）轉向生產環境時，常因開發環境與實際基礎架構脫節，導致需重新設計架構，耗費大量時間與預算。

Agent Studio 解決了這個斷層：在視覺化介面開發的原型即是產品，每個 Flow 都能直接轉換為 REST API 端點，無需額外的工程交接即可部署。

視覺化開發與 Python 擴充性

透過拖拉式介面，開發者能快速串接 LLM、儲存空間與資料源，並在部署前驗證邏輯。

當需求變得複雜時，系統也支援完整的 Python 擴充性，確保開發不受限。這種設計兼顧了開發效率（拖拉式）與細膩控制（寫程式），讓企業能根據需求彈性選擇。

企業級部署的核心能力：

• MCP (Model Context Protocol) 支援：任何 Flow 都能作為 MCP 伺服器供其他 Agent 或應用程式調用，支援企業建構模組化的多 Agent 協作架構。
• 安全 Agent 記憶體：將中間狀態與工具輸出儲存在本地的 Postgres 中，避免敏感資料傳輸至公用 LLM，滿足金融、醫療與電信等高度合規產業的需求。
• Agent 生命週期管理：整合 LangSmith、Langfuse 等觀測性工具，並內建 Agent Lifecycle Toolkit (ALTK)，在進入生產環境前預先識別推理邏輯或輸出品質的問題。

EDB 選擇以 Langflow 為基礎，反映了其擁抱開源技術的原則。這讓開發團隊能利用活躍的社群生態快速迭代，同時避免被單一廠商綁定，確保技術架構能跟上 AI 領域的快速演進。

向量資料庫升級：VectorChord 雙架構

AI Agent 的表現取決於資料的即時性與索引品質。

為了滿足不同規模的技術需求，新一代 AI Factory 對內建的向量資料庫功能進行了重大升級：在保留 pgvector 的同時，新增了 VectorChord 索引選項，讓 Postgres 在單一平台上展現專用向量資料庫的效能。

適應不同規模的索引選擇

對於多數企業的 RAG 應用，pgvector 仍是首選，能穩定處理千萬級別的向量資料。

然而，當 AI 應用規模擴展至「億級」向量、維度更高且需支撐數百個並發查詢時，傳統的 HNSW 索引在建立時間、記憶體消耗與吞吐量上會面臨挑戰。

VectorChord 正是為了突破此瓶頸而設計，其具備以下技術優勢：

• 超越專用向量資料庫的效能：採用 IVF-RaBitQ 索引架構，索引速度較 pgvector 快 100 倍，並在維持 95% 以上召回率（Recall）的前提下，提供 5 倍快的查詢速度。
• 高效率資源利用：處理 1 億筆 768 維向量時，在僅 32GB 記憶體的環境下，P50 延遲僅為 35ms。與**專用向量資料庫（如 Pinecone）**相比，每一塊錢能處理的向量數量高出 6 倍。
• 無痛升級：完全相容 pgvector 的資料型態與語法。企業可根據需求隨時切換索引，無需修改應用程式程式碼或遷移至其他資料庫。

三大效益：

1. 即時性與響應速度：更快的索引速度縮短了知識庫更新的延遲，讓 Agent 能基於最新資料運作，提升輸出的準確度與用戶體驗。
2. 資料主權與掌控：所有向量資料原生儲存在 Postgres 中，無需額外維護外部向量資料庫，降低資料外洩風險與治理成本，適合地端或隔離環境部署。
3. 規模化下的成本優勢：VectorChord 優異的儲存與記憶體效率，讓企業無需投資昂貴的專用硬體，即可在現有的 Postgres 環境中運行十億級規模的 AI 工作負載，實現資料庫架構的精簡與整合。

在可控資料架構下落實 AI 應用

AI Agent 的競爭關鍵在於穩定、安全且具備規模化的技術架構。EDB Postgres AI Factory 透過整合視覺化開發工具、高效能向量引擎與自動化 Pipeline，協助企業在完全掌控資料的前提下，大幅縮短從原型開發到生產環境的部署時程。

這套整合方案讓團隊能隨著 AI 技術演進靈活切換模型，且無需更動底層基礎架構，確保 AI 計畫能真正落地並產生實質的商業價值。

本文翻譯自：The Next Generation of EDB Postgres AI Factory: Built for the Agent Era

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

目前僅 13% 的企業成功將 AI Agent 專案導入生產環境，主因在於基礎設施限制。根據 EDB 的調查，企業急需一個能直接掌控，並統一處理交易、分析與 AI 工作負載的平台。

傳統資料堆疊因拼湊舊系統與各家雲端平台，導致資料自主權風險、效能不穩且成本難以預測。EDB Postgres® AI 提供 PB 級效能並節省 58% 成本，且無供應商鎖定（Vendor lock-in）。

PB 級分析：穩定效能與可預測成本

全方位資料倉儲監控與管理

EDB 致力於提升 Postgres 的分析引擎實力。根據 McKnight Consulting Group 的測試，WarehousePG 對比 Snowflake 與 Databricks 等雲端資料倉儲，表現如下：

• 成本效益： TCO 最高節省 58%，採用可預測成本模型，無隱藏費用。
• 高穩定性： 在高併發負載下，效能穩定度高出 52%。
• 部署彈性： 支援雲端、地端、隔離環境（Air gapped）或混合雲。

圖 1：EDB Postgres AI 對比雲端資料倉儲可節省 58% TCO。

維運優化：WarehousePG Enterprise Manager (WEM)

測試證實，PB 級分析不需依賴封閉平台或雲端綁定。為簡化維運，EDB 推出 WEM 管理工具，提供視覺化介面取代複雜的指令列，讓叢集管理與監控更直覺。

圖 2：WEM 視覺化介面提供單一窗口管理與監控 WarehousePG 叢集。

WEM 整合了即時遙測、AI 輔助開發與互動式配置功能，將複雜的分散式資料庫操作整合至單一管理介面。管理者可直接進行叢集健康檢查、SQL 效能調校，並在高效能環境中管理安全性。

透過大規模擴展能力與簡化管理的結合，EDB Postgres AI for WarehousePG 為 AI Agent 時代的維運需求提供了更簡便的標準。

推薦閲讀：分析型資料庫一定要多叢集？EDB WarehousePG 有不同做法

GPU 加速讓分析效能提升 91 倍

除了強化資料倉儲，EDB 也持續提升維運資料的分析速度。上個月在 NVIDIA GTC 大會上，EDB 發佈了 PGAA 擴充功能與 NVIDIA RAPIDS for Apache Spark 的深度整合。

透過 Spark 的橫向擴展能力，並將計算密集型的分析工作負載卸載至 NVIDIA GPU，企業可消除傳統 CPU 的效能瓶頸。此 GPU 加速技術讓即時維運資料的分析查詢速度提升高達 91 倍，提供 AI Agent 即時處理與決策所需的高吞吐量與次秒級延遲。

使用 EDB Postgres AI 構建自主 Agent

根據 Gartner 預測，企業在 AI 資料庫系統的支出將於 2028 年增長三倍。Gartner 在報告中肯定了 EDB 具備 AI Agent 資料庫的三大關鍵角色：作為長期記憶、核心知識來源，以及任務執行的可靠引擎。

本季度 EDB Postgres AI 推出新一代更新，簡化了直接在現有資料上構建 Agent 的流程。這些功能旨在提供整合工具，協助團隊銜接原型開發（Prototype）與生產環境（Production）之間的差距，並有效地驅動資料與編排 Agent 行為。

EDB 向量資料庫

AI Agent 的工作流品質，完全取決於底層向量資料庫知識庫的效能。本季度 EDB 強化了內建的向量引擎，推出高效能的 VectorChord，為企業提供更強大的 Postgres 向量資料庫解決方案，作為 pgvector 的高階補充方案。

此次更新為不同工作負載提供彈性的索引策略：

• pgvector： 仍為多數 RAG 應用的標準規格。
• VectorChord： 專為規模達十億級向量的企業級向量資料庫需求設計，提供隨插即用的升級體驗。其索引速度提升 100 倍，具備高併發多 Agent 系統所需的次秒級延遲。

Agent Studio 實現視覺化 AI 開發

EDB Postgres AI 的 Agent Studio 現已與 Langflow 整合，提供直觀的視覺化拖拉介面來構建、測試與部署 Agent。使用者可從零開始設計，或使用開源模板與自定義組件。

為強化 Agent 編排與資料之間的連結，EDB 在 Langflow 中引入了 MCP Server、資料庫與嵌入組件。透過 MCP（Model Context Protocol） 開放標準，Agent 能直接將 Postgres 資料庫作為工具進行互動，大幅消除自定義整合的障礙並提升連線安全性。

圖 3：EDB Postgres AI 的 Agent Studio 整合 Langflow 拖拉式介面，支援從零開始構建、使用開源範本或自定義模板，快速開發與部署 AI Agent。

AI Pipelines 現已支援多步驟流程的點選式配置（Point-and-click），統一資料準備與嵌入步驟，達成「一次構建、統一維護」。針對 SQL 使用者，AIDB 擴充功能強化了 PDF 解析與資料庫內建 LLM 能力，僅需幾行 SQL 指令即可原生導入複雜文件，並將非結構化資料自動摘要為具參考價值的資訊。

此外，模型推論（Model serving）功能現在可直接連接 Hugging Face 等供應商，無需手動編寫整合代碼（Glue code）。將模型直接對接平台，能有效減少資料移動、提升安全性，並確保 AI 堆疊的自主掌控權。

大規模 AI 基礎設施管理

AI Agent 時代不僅改變了開發模式，也改變了維運與基礎設施的管理邏輯。EDB 透過自然語言與業界標準自動化技術，簡化了企業對整體資料環境與基礎設施的管理流程。

自然語言簡化維運流程

EDB Postgres AI 現已內建聊天機器人（Chatbot），支援透過自然語言管理平台，無需編寫腳本。管理員可直接透過對話簡化以下任務：

• 建立或編輯遷移專案
• 修改使用者角色與權限
• 直接獲取效能與健康檢查建議

這項功能將手動操作轉化為互動式對話，朝向自動化管理邁進，讓團隊能專注於更具策略性的工作。

圖 4：EDB Postgres AI 內建聊天機器人，支援以自然語言提問並獲取資料庫與整體環境的建議，無需編寫程式碼即可快速獲得分析資訊。

瞭解，這段關於自動化與高可用性的內容，我將其併入前面的段落，並維持極簡、技術導向的風格：

此外，EDB 推出了自動化存儲擴展（Autonomous storage scaling），能根據工作負載自動增加容量。管理員可預設維護視窗或存儲上限，無需手動干預或預先配置過多資源，即可確保應用程式持續運行。

針對無法容忍停機的關鍵任務，Hybrid Manager 現已支援三地部署，提供 99.999% 的高可用性。這確保企業營運不會因單一區域或資料中心故障而中斷，強化業務連續性。

Red Hat Ansible 認證的自動化架構

EDB 與 Red Hat 共同驗證了參考架構，為 Red Hat Ansible Automation Platform (AAP) 提供高韌性的資料層。針對關鍵任務的自動化平台，穩固的基礎設施是確保業務流程不中斷的核心。

EDB Postgres AI 與 AAP 整合提供以下優勢：

• 高可用性（HA）： 支援多可用區（Multi-AZ）韌性，可在 30 秒內完成自動容錯移轉。
• 災難復原（DR）： 提供強大的跨區域保護，確保營運不中斷。
• 無縫部署： 原生整合 Ansible，支援全堆疊自動化流程。

目前每一版 AAP 釋出前皆會針對 EDB Postgres AI 進行完整測試，確保企業具備經認證、可投入生產環境的大規模自動化基礎。

本文翻譯自：EDB Postgres® AI Q1 2026 Release Highlights

想瞭解更多 EDB Postgres® AI 的應用與導入建議？歡迎聯絡我們，或是 加入歐立威 Line 好友！

面對激增的資料量與使用者需求，傳統「多叢集架構」的管理難度與效能優化挑戰日益嚴峻，分析團隊往往陷入「控管預算」而非「產出洞察」的困境。

本文將探討 EDB WarehousePG 的創新架構，如何在不增加運算成本的前提下，完美支撐高併發查詢。

為何傳統雲端架構難以應付 BI 工作負載？

雲端資料倉儲是為了處理大規模資料工程與排程分析而設計，目的是在執行批次 ETL 或機器學習任務時能有效利用資源。用量計價的模式可以讓系統在任務執行時使用資源，完成後自動釋放，降低不必要的成本。

商業智慧（BI）系統的使用節奏

BI 與傳統排程分析不同。業務人員全天刷新儀表板、資料科學家執行探索性查詢、財務分析師生成報表，AI agent 也同時提供對話式分析。這種同時操作的模式對系統資源與效能管理帶來極大挑戰。

不同平台在處理高併發 BI 使用者時的資源分配方式差異很大：有些平台會啟動多個叢集，有些只需要少量叢集；排隊時間可能從瞬間到 30 秒以上；查詢失敗率最高可達 4%。

即便是相同工作負載，成本也可能因自動擴展方式不同而差異高達 73%。這些都顯示，高併發 BI 的架構設計對成本與效能影響非常明顯。

AI 自動化查詢帶來的挑戰

BI 不只來自人類使用者，AI agent 也會自動查詢資料庫，增加更多併發負載。

每個 AI agent 像超級使用者，數秒內執行數百筆查詢，並根據結果決定是否發出更多查詢。即便資料倉儲能跟上，高併發 BI 也會讓成本迅速飆升，迫使分析團隊將時間花在控管資源，而非專注於產出洞察。

架構為何影響高併發工作負載？

雲端資料倉儲原本針對間歇性任務設計，能在突發需求時快速擴充運算資源，任務完成後再自動釋放。這對批次 ETL、機器學習訓練或週期性分析非常適合，彈性架構與用量計價相輔相成。

但高併發 BI 工作負載並非突發，而是可預測的持續需求。即便有 AI agent 參與，整體查詢模式仍高度可預測：你大致知道上班時間內有多少分析師與 agent 同時查詢資料。

問題在於：當為突發負載設計的平台遇到可預測的高併發查詢時，成本反而難以控制。使用者越多，啟動的叢集越多，帳單越高，即便實際使用模式沒有改變。

簡單來說：彈性架構會帶來彈性成本，而非彈性的工作負載反而造成錯配。

Postgres 替代方案：可預測的效能與成本

Postgres 為基礎的資料倉儲採取了完全不同的方法。基於 MPP（Massively Parallel Processing）大規模平行處理架構，經過數十年驗證技術，可以在不需要多叢集協調的情況下處理高併發工作負載。

圖 1：MPP 架構透過將資料列與運算分散到多個獨立的 segment 主機上來擴展效能

Segment 協調器會建立最佳執行計畫，指示每個 segment 如何並行處理其專屬的資料區塊（例如 16 個 segment 各自處理 16M 列資料表中的 1M 列）。

獨立基準測試顯示這種方法效果非常顯著。初步結果指出，Postgres 架構在高併發、高容量分析工作負載下可節省成本高達 62%，在併發擴展效率上比主流雲端資料倉儲高出 63%，同時維持可預測的成本結構與一致的使用者體驗。完整基準結果將在未來幾週公開。

對於關鍵業務操作來說，穩定性至關重要。MNTN，一個管理 PB 級資料的領先連網電視廣告技術平台，多年來一直使用 Postgres 資料倉儲。他們對效能一直滿意，但需要一個開源替代方案以及企業夥伴，來保證營運不中斷並提供快速支援。EDB Postgres AI for WarehousePG 就是他們的解決方案。MNTN 的資料主管 Greg Spiegelberg 表示：「效能穩定，系統可靠，支援快速，正如應有的。我很安心，即使半夜遇到問題，也有人能協助我，不必自己手動修改開源程式碼來恢復資料庫。」

EDB WarehousePG：單叢集處理高併發 BI

當你掌握每天的儀表板刷新、定期報表週期以及分析師查詢模式時，高併發 BI 工作負載其實是可預測的，無需冒高風險去更換基礎架構。

差異在於可預測性：

• 用量型平台（Consumption-based）：針對突發、不可預測的負載優化，你按使用量付費，但「實際使用量」會受到隱藏變數影響，例如平台自動擴縮的積極程度、叢集保持活躍的時間、查詢是排隊還是立即執行，以及為應對併發需求啟動了多少叢集。
• 容量型平台（Capacity-based）：針對已知負載優化，你根據併發需求配置運算核心，無論執行 1,000 筆還是 100,000 筆查詢，成本都保持固定。當平台需要啟動 3~5 個額外叢集應對高峰併發時，容量型成本不受影響。

對大多數已建立 BI 工作負載的企業而言，可預測性往往比彈性更重要。

轉換到容量型平台不代表必須拆掉現有架構。WarehousePG 基於 Postgres，團隊可立即使用熟悉的 SQL 技能。對於已在使用 Greenplum 的組織，轉換只需簡單的二進位替換（binary swap），可在數小時內完成，而非數月。

歐洲泛歐市場基礎設施 Euronext FX 就採用了這種轉換，藉此避免被既有 Greenplum 供應商綁定。Euronext FX 全球 CTO Grigoriy Zeleniy 表示：「我們很高興能與 EDB Postgres AI 合作。它對 Greenplum 工作負載的支援，讓我們能掌控開源軟體的部署位置與方式。」WarehousePG 提供了無縫二進位替換，並在四個全球資料中心提供卓越企業支援與開源控制。

在 GDPR、資料存放地要求以及日益嚴格的法規監管下，這種掌控力非常重要。組織必須確切知道資料存放位置與存取權限，同時不犧牲效能與可預測性。

除了成本可預測性，WarehousePG 的 MPP 架構 可處理大量報表與高併發 BI，並透過工作負載管理優先處理關鍵查詢。內建 向量化功能（pgvector） 支援 AI 特徵工程與模型訓練，可直接在資料上操作，不需將資料移到其他基礎架構。即時資料流（streaming ingestion）支援即時日誌與事件分析，跨資料湖的聯邦查詢打破資料孤島，無需複雜 ETL 流程。

推薦閲讀：EDB Postgres 向量搜尋怎麼做？核心技巧公開

選擇適合的架構與定價模式

如果高併發 BI 工作負載出現不可預測的成本，你並不孤單。雲端資料倉儲的用量計價模式，雖然對資料工程非常吸引人，但對商業智慧分析而言，經濟效益可能不同。

透過容量型架構與 EDB Postgres AI for WarehousePG，獲得明確的優勢：

• 成本可預測：按核心計價，取代用量計費
• 操作簡化：管理的系統元件減少，小型團隊也能輕鬆維護
• 效能提升：與 Tableau 直接連線，無需額外抽取流程
• 維持資料主權：資料可留在 VPC 中，符合法規要求

重點不在於現代雲端平台能否擴展（它們當然可以）。關鍵是，你是否為多叢集與彈性擴縮付費，而你實際需要的只是可預測的效能與可控成本。

立即體驗 EDB Postgres AI for WarehousePG！看看 Postgres 架構如何處理高併發 BI 工作負載並保持成本可預測，或聯繫我們的團隊進行工作負載評估。

本文翻譯自：Why Your Analytical Database Needs Multiple Clusters to Do What WarehousePG Does With One

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

什麼是向量搜尋？為什麼重要？

向量搜尋依據語意或資料特徵找到相似內容，即使文字或數值完全不相符。

例如，查詢「如何重設密碼？」時，系統仍能找到《登入憑證重設步驟》，即使字詞不同。這種以語意而非文字匹配的能力，是建構智慧應用的關鍵。

向量搜尋應用廣泛，包括：

• 語意搜尋：理解查詢意圖，超越關鍵字比對。像客服平台輸入「無法登入」，仍可找到「密碼重設」文章。
• 文件檢索：將報告、知識庫或工單轉為向量，快速找到最相關內容，並支援 RAG 提供上下文答案。
• 文件比較：銀行、保險或稽核可比對大量文件，即使改寫或重組，也能找出重複或相似內容。
• 圖像相似性搜尋：向量可表示視覺特徵，電商推薦相似商品，媒體檢測重複或近似圖片。
• 推薦系統：將使用者與商品向量存於 Postgres，依語意相似度推薦商品、電影或文章，考量偏好、購買紀錄或評論情感。

透過 EDB Postgres 的 pgvector 擴充功能，向量資料可直接存放、索引與查詢，讓 AI 任務與企業現有交易或分析工作無縫整合。

向量搜尋如何運作？

向量搜尋的運作方式，是將資料轉成向量（embedding），再依相似度找出最相關內容。具體流程可分為四個步驟：

1. 向量生成：使用模型（如 OpenAI、BERT、CLIP）將文字、圖片或音訊轉為多維浮點數向量，就像為語意建立「GPS座標」，概念相似的向量會聚在一起。
2. 存放於 Postgres：透過 pgvector 將向量存入專用欄位，每列對應一份文件、圖片或資料紀錄。
3. 相似度搜尋：查詢先轉為向量，再比對資料庫向量的相似度（如餘弦距離或歐氏距離）。
4. 排序與回傳：系統依相似度分數排序，回傳最相關結果。

這種架構簡單卻強大，將結構化資料、非結構化資料與向量搜尋整合在同一 Postgres 平台中，實現高效、統一的搜尋體驗。

向量搜尋的相似度指標

向量搜尋的核心在於比較向量，找出哪些已存向量最接近查詢向量。不同的距離指標決定了「相似度」的計算方式。

兩個最常用的指標是 餘弦相似度 (Cosine Similarity) 與 歐氏距離 (Euclidean Distance)，兩者皆由 pgvector 原生支援。

向量搜尋的索引與擴充

當資料量從數千筆向量增加到數百萬筆時，逐一比對每個向量的「暴力搜尋」成本太高，這時向量索引就很重要。

什麼是向量索引？

向量索引會將向量依特徵分群或組織，讓系統能快速找到相似向量，而不需掃描整個資料集。

常見向量索引類型

• IVF（Inverted File Index）：將向量分成多個群集，僅在最相關群集內搜尋。
• HNSW（Hierarchical Navigable Small World）：圖結構索引，將相似向量連結，提供超快查詢速度。
• PQ（Product Quantization）：將向量壓縮成較小表示，降低儲存與計算成本。

近似最近鄰搜尋（ANN）

ANN 能有效擴充向量搜尋規模，不必找出精確最近鄰，只找到「近似最近鄰」，以極小精度換取大幅效能提升。

對於即時 AI 場景，如：聊天機器人、推薦系統或語意搜尋等，ANN 索引提供了速度與精準度的理想平衡。

EDB Postgres AI 向量搜尋

雖然市面上出現許多新向量資料庫（如 Pinecone、Milvus、Weaviate 等），企業仍偏好 EDB Postgres，原因包括：

• 統一平台
  利用 pgvector，無需額外資料庫存放向量，AI 工作負載可直接在處理交易或分析資料的 Postgres 實例中運行，架構更簡單。
• 企業級可靠性
  EDB Postgres 延續 Postgres 多年的穩定性，提供企業級可靠性、複寫與高可用性，適合關鍵任務，不同於實驗性向量資料庫。
• 無縫整合
  支援各種擴充套件、FDW 與整合框架，讓結構化資料、向量與外部 AI 模型能混合分析。
• 彈性擴充
  搭配 EDB Postgres Advanced Server、WarehousePG 或 Postgres Distributed，可跨節點擴充向量運算，同時兼顧分析效能與向量相似度搜尋。
• 治理與安全
  金融、公共單位等行業對資料治理與自主管控要求高，在 EDB Postgres 上執行向量搜尋可確保資料主權、稽核與合規性。

結語

在生成式 AI 的應用中，向量搜尋是核心，但穩定性才是落地關鍵。透過 EDB Postgres 與 pgvector 的整合，你可以在熟悉的 SQL 環境中處理語意搜尋與 RAG，不需要額外維護一套複雜的專用向量資料庫。

推薦閲讀：資料庫遷移全攻略：掌握變更管理一次看懂

本文翻譯自：Getting Started with Vector Search in EDB Postgres

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

EDB PEM 是管理 PostgreSQL/EPAS 的大腦。雖然 PEM 當機不影響資料運作，但維運團隊會瞬間變成「瞎子」，失去告警與自動化管理能力。要達成真正的全時穩定，PEM 本身的 HA 設計，才是完整方案中不可或缺的最後一哩路。

為什麼需要 PEM HA？

簡單來說，當監控系統癱瘓時，維運團隊就失去了判斷現況的「眼睛」。 在 EDB 的企業級架構中，PEM 不僅是個看板，更是核心的神經中樞：

• 集中式監控：收集所有 Postgres / EPAS、Barman、pgBouncer … 等資訊
• 告警（Alerting）：發出 Email、SNMP、Webhook 告警
• 效能診斷（Performance Diagnostics）

一旦 PEM Server 無法提供服務：

• 通知與告警中斷
• 監控與歷史趨勢資料中斷
• 自動化工作無法執行
• 監控代理 PEM Agent 無法上傳資料
• 管理者難以判斷高可用切換後的叢集狀況

對大型環境（>20+ DB instances）是一個不可忽視的風險。因此，在企業級資料庫環境中，為了實現完整的高可用管理鏈，PEM HA 是一個不可忽略的部署元件。

PEM HA 同地 / 異地架構概念

PEM 同地高可用架構的基本核心架構：

• 透過 streaming replication 將PEM Server 後端資料同步於 primary / standby
• PEM Server 使用虛擬 IP（VIP）提供單一服務入口點
• PEM Agents 全部指向 VIP，而不是指向單一 PEM Server
• PEM Server 故障切換後，PEM Agents 會自動重新連線

針對以上核心原則，PEM 同地 HA 架構會如下圖呈現：

説到這，其實你會發現 PEM HA 與資料庫的 HA 有著一模一樣的核心架構。

透過 EDB 提供的 Failover Manager，使PEM server 也可以綁定 Virtual IP 並且達成自動故障切換，進而減少因 PEM 故障而產生的 downtime 時間。

PEM HA 與資料庫 HA 有著相似的特性 ：在資料庫的高可用架構中，唯有 Primary 可提供讀寫功能在PEM 高可用架構中，所有的連線（包含Web UI）都只會指向 Primary。

那 PEM 可以達成異地高可用架構嗎？

自 PEM 10.1 版本開始，PEM Server 在高可用架構上有了更彈性的部署方式。

以同地高可用架構為例，若要讓 PEM Server 本身具備高可用能力，通常會搭配 Failover Manager（EFM） 與 Virtual IP（VIP），形成 Primary / Standby 的雙機架構。然而，VIP 受限於 Layer 2 網段，無法跨區域使用，因此若想將 PEM Primary 與 Standby 部署在不同機房或地理區域，就會受到架構限制。

自 PEM 10.1 開始，PEM Server 支援 PostgreSQL 的 multi-host connection string，使 PEM Agent 以及 PEM 本身都能同時連接多個主機，進一步提升異地高可用的可行性。

這代表：

• PEM Primary 與 PEM Standby 可以分別部署在不同地區、不同網段
• 不再依賴 Virtual IP
• Agent 在 Primary 不可用時，可自動切換連線到新的 primary
• 整體架構更彈性，也能真正做到跨區域的高可用

實際架構看起來會像這樣：

PEM HA 同地 / 異地 實際測試

如何建立 PEM 監控的高可用架構呢？我們先來簡單介紹其組成元件。

• 兩台 PEM Servers
  • 主節點：PEM Primary (範例 ip → 172.16.1.76)
  • 備援節點：PEM Standby (範例 ip → 172.16.1.77)
• 資料同步
  • 建議使用 EDB 整合的 Streaming Replication
  • synchronous / asynchronous 取決於可用性 vs 性能
• Virtual IP
  • 透過 EDB Failover Manager 將 virtual ip (172.16.1.155) 綁定至各主機上
• PEM Agent
  • 透過資料庫主機上 PEM Agent 的設定來決定Failover 發生時資料庫該連向哪一個 PEM Server

PEM HA 同地 高可用架構（EFM + VIP）

將 PEM primary 設定好後，透過 streaming replication 將 PEM standby 也同步到 PEM primary 的資料，並且將兩個節點都加入到 Failover Manager 的叢集內，會呈現以下狀態：

可以看到我們已經將 virtual ip 透過 Failover manager 綁定到兩台 PEM Server，再到資料庫主機端的 PEM Agent 設定檔去修改要連線的 ip 。

上圖就是在資料庫端所安裝的 PEM Agent 的設定檔。

PEM Agent 欲連線的 PEM Server 的 ip 以及 port，還有其運作過程所產生的 log 的位址等設定都會存取在該設定檔裡面。

只需要將第一項設定 pem_host 修改成我們前面設定的 virtual ip,，將 PEM agent 服務重啟後，監控資料就能順利指向 PEM Server 所綁定的 virtual ip。

當 failover 狀況發生時，由於我們指向的目標 ip 是 virtual IP，無需手動更改資料庫連線的資訊，virtual ip 就會自行綁定至當前可提供服務的 PEM server。

以下嘗試將 PEM primary 的資料庫服務停止（systemctl stop postgresql-17）：可以看到 EFM 狀態顯示 PEM Primary 斷線，並且 EFM 自動將 standby promote 成 primary。

透過 virtual ip 去訪問 PEM web 介面，可以發現服務是依舊正常顯示：

這樣一來就成功驗證了 PEM 同地 HA 架構的可行性！

PEM HA 異地 高可用架構（EFM + Multi-host connection）

如前文所述，VIP 天生受到 Layer 2 網段限制，而無法跨區域部署。我們可以透過 PEM 10.1 版本之後支援的 multi-host connection， 來達成部署異地PEM的高可用架構。

基本上，唯一與同地高可用架構不同之處，就是 PEM Agent 端的設定檔案。

在修改設定檔案之前，我們先看當前 EFM 叢集狀態：

因為沒有額外綁定 Virtual IP 在資料庫的主機上，可以看到這次狀態的頁面在 VIP 的欄位是空白的。

接著就到 PEM Agent 設定檔，新增兩台 PEM Server ip 。

過去 PEM Agent 設定中，pem_host 欄位只允許一組 PEM server ip。但自 PEM 10.1 版本開始，該設定檔便支援了填入一組以上的 ip 。

現在只要將兩台 PEM server 的 ip 依照 primary >> standby 的順序填入後，PEM Agent 就會自行依照順序去尋找當前可供讀寫（當前 primary）的 PEM host， 進行後續的連線。

接下來，實際將當前的 PEM Standby promote 成新的 primary，並且觀察是否可以透過 PEM standby 進行連線。

透過 efm promote <叢集名稱> –switchover 將原先的 standby promote 成 primary：

由於 PEM HA 有著與資料庫 HA 相同的特性（連線一律指向 Primary），可以看到我們用 PEM 舊 primary ip 是無法訪問 Web UI 介面的：

相反的，這時就可以透過 PEM standby（新的 primary） ip 去做訪問：

這樣一來，我們也驗證了如何透過 multi-host connection 去達成 PEM 的高可用架構！

結語

在 PostgreSQL / EDB 高可用架構中，PEM 的角色比多數人想像中來得更加關鍵。若資料庫本身已經做到 PG / EPAS HA，但監控平台仍是單點，就等於整個 HA 架構仍有進步的空間。

透過引入 PEM HA：

• 整個 PostgreSQL 監控、管理、告警與自動化流程都能具備高可用性
• 真正達到企業級的完整資料庫 HA 生態

如果您的企業正在規劃或已經部署 PostgreSQL 高可用架構，建議下一步就是將 PEM 納入 HA 設計，讓整個系統達到更完整的韌性與可靠性。

文章參考資料：

[1]  EDB Official Document 

[2] https://www.enterprisedb.com/docs/pem/latest/considerations/ha_pem/#connections-must-go-to-the-primary

[3] https://www.enterprisedb.com/docs/pem/latest/considerations/ha_pem/#multi-host-connection-strings

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

透明資料加密（Transparent Data Encryption，TDE） 是一種資料庫加密機制，透過檔案層級加密來保護靜態資料（data at rest），確保儲存在硬碟與備份媒體中的資料不會被未授權存取，並協助企業符合 PCI DSS 等資安與法規要求。

在 EDB Postgres Advanced Server 15 與 EDB Postgres Extended Server（EDB Standard Plan） 中，TDE 為選用功能，透過金鑰管理機制控管資料存取權限，只有具備授權金鑰的使用者才能解密資料，進而保護敏感與機密資訊。

相較於尚未支援 TDE 的 Community Postgres，EDB Postgres 更能滿足高度監管產業與政府單位對靜態資料加密與合規性的需求，也讓企業能在高資安門檻下順利導入 Postgres。

TDE 加密範圍

TDE 保護靜態資料，但仍有部分系統資訊與檔案不在加密範圍內。

TDE 運作原理

TDE 透過加密資料庫伺服器與備份儲存的作業系統檔案。即使資料被竊取或遺失，也無法被未授權使用者解讀。

資料庫本身負責加解密流程，無需修改應用程式或更新客戶端驅動程式。

此外，EDB Postgres Advanced Server 與 EDB Postgres Extended Server 提供外部金鑰管理整合介面，可支援簡單的密碼加解密操作，或與企業級金鑰管理系統整合。

PostgreSQL 透明資料加密（TDE）

在 PostgreSQL 中，TDE 用於加密靜態資料，包括表格、索引及寫前日誌（WAL）檔案，而無需修改應用程式。PostgreSQL 本身不原生支援 TDE，多數情況需透過第三方擴充套件（如 pgcrypto）或檔案系統層級加密（如 LUKS、BitLocker）來實現。

TDE 可保護資料檔案、日誌與備份，即使物理儲存遭入侵，資料仍能保持安全。使用 pgcrypto 可對單一欄位加密，提供更細緻控制，但需應用程式指定加密資料；檔案系統層級加密則自動處理，但可能增加系統負擔。

此外，TDE 依賴金鑰管理系統安全存放與管理加密金鑰，確保未授權存取受控。

TDE 典型應用場景

TDE 適用於各種需要保護靜態敏感資料的場景，以下為代表性案例：

一、金融服務

客戶帳戶資料、交易紀錄與個人識別資訊透過 TDE 加密，降低資料外洩或誤用風險，減少可能的金錢損失，同時協助符合 PCI DSS 等金融法規要求。

二、雲端存儲

當企業將資料遷移至雲端時，TDE 可在資料上傳前加密，確保敏感資訊安全隔離，避免與其他租戶資料混淆或誤取，保障多客戶共用基礎設施的資料安全。

爲什麽需要 TDE？

資料外洩風險持續存在，無論企業規模大小，都可能造成財務損失、法律責任與合規問題。

TDE 能保護資料庫中靜態資料，即使儲存媒體遭到入侵，也能防止未授權使用者讀取敏感資訊。TDE 是整體資料安全策略的基礎組件，但它只是眾多安全工具之一。

Postgres 以完整的加密能力聞名，能協助企業降低成為外洩事件目標的風險，並提升資料保護與合規性。

TDE 還能做什麼？

金鑰管理

金鑰管理對 TDE 至關重要，可防止未授權存取敏感資料。建議定期輪換加密金鑰、設定金鑰過期策略，並限制僅必要的人員或服務存取。

效能優化

加密與解密會增加系統負載，可能影響資料庫效能。可透過硬體加速、調整資料庫設定並定期監控系統來降低影響。

存取控制

確保只有授權使用者或流程能存取加密資料，並可透過角色設定限制使用者僅存取與其職責相關的資料。

例行稽核與檢查

定期檢查 TDE 是否符合組織政策與法規要求，稽核可自動化，並記錄誰存取資料、何時存取，以及執行的操作。

與組織策略對齊

實施 TDE 時應符合整體資料保護策略、資安政策與風險管理框架，並考量加密需求與法規遵循，同時明確規範加解密流程、金鑰管理與稽核角色，確保監督與問責。

災難復原規劃

將 TDE 納入災難復原計畫，可在系統故障或資料遺失時，順利還原加密資料。

總結

TDE 能有效保護靜態資料，降低外洩風險，並協助企業符合法規要求。透過妥善的金鑰管理、存取控制與效能優化，TDE 不僅保障敏感資訊安全，也支援企業在多種應用場景下落實資料保護策略。

無論是在金融、醫療、或其他高度監管的環境中，TDE 都是企業資料安全規劃中不可或缺的核心工具！

本文翻譯自：What is Transparent Data Encryption (TDE)? Benefits, Types, and Best Practices

歡迎聯絡我們，或是 加入歐立威 Line 好友！

什麼是 SQL 注入（SQLi）？

SQL 注入（SQL Injection，SQLi）是一種網路攻擊，攻擊者透過操控網頁應用程式輸入，將惡意 SQL 指令注入資料庫查詢。

這類漏洞通常出現在應用程式未驗證輸入或未使用參數化查詢時。攻擊可能導致敏感資料外洩、資料被竄改，甚至整個資料庫遭刪除，駭客在某些情況下甚至可取得管理權限。

SQL 注入的典型攻擊手法

只要應用程式沒有驗證輸入或未採用參數化查詢，任何表單、搜尋框、登入欄位都可能成為 SQL 注入的入口。理解常見的攻擊情境與操作方式，有助開發者提前辨識弱點並建立更完善的防護。

In-band SQLi（同頻道 SQL 注入）

示例：攻擊者在登入欄位輸入像 admin' OR 1=1 -- 這類惡意字串，使查詢條件永遠為真。
結果：無須密碼就能直接登入系統。

Union-based SQLi（UNION 聯合查詢注入）

示例：在搜尋欄位輸入：shoes' UNION SELECT username, email FROM users --
攻擊者利用 UNION 把惡意查詢與合法查詢合併。
結果：原本應顯示產品資訊的頁面，會被迫顯示使用者帳號、Email 等敏感資料。

Error-based SQLi（錯誤回傳式注入）

示例：攻擊者輸入破壞語法的字元（如 '），藉由資料庫回傳的詳細錯誤訊息推敲：資料表名稱、欄位名稱、資料庫架構
結果：攻擊者可利用這些資訊打造更精準的後續攻擊。

SQL 注入攻擊的風險

SQL 注入帶來的危害不只停留在技術層面，從品牌信任、法規遵循到敏感資料外洩，都可能對企業造成深遠影響。以下將從三大面向說明其主要風險。

品牌與財務衝擊

成功的 SQL 注入攻擊可能導致客戶資料外洩、帳號被盜用或未授權的金流操作，對企業造成嚴重損害，削弱客戶信任，並帶來營收損失、法律費用及高額資安事件處理成本。

合規風險

處理敏感個資或財務資料的組織通常需遵守 GDPR、HIPAA 與 PCI DSS 等法規。若發生 SQL 注入造成資料外洩，可能違反法規，面臨重罰與監管單位嚴格審查。

敏感資料外洩

SQL 注入可暴露使用者帳號、身分證號、財務資料或企業機密等敏感資訊。這些資料除了立即風險外，也可能被轉售或用於後續攻擊，加重損害。

SQL 注入防護技巧

防止 SQL 注入需要結合安全程式設計、資料庫設定與監控工具，從多層面降低攻擊風險。

參數化查詢與預備語句

使用參數化查詢可確保使用者輸入被當作資料處理，而非可執行程式碼。預備語句允許開發者在 SQL 模板中使用佔位符，避免直接串接或拼接輸入。

資料庫稽核與監控

持續監控資料庫活動，可偵測可疑查詢或異常存取行為。稽核日誌提供歷史紀錄，對事件分析與法規遵循非常重要。

儲存程序（Stored Procedures）

將資料庫邏輯封裝在儲存程序中，可控制 SQL 指令執行。透過程序內驗證輸入與限制直接存取資料表，減少注入風險。

內建 SQL 安全性的 ORM 框架

ORM（物件關聯對應）框架如 Hibernate 或 SQLAlchemy，自動處理查詢構建，可降低 SQL 注入機率。但開發者需避免用 raw SQL 覆蓋 ORM 查詢，以免破壞安全防護。

輸入驗證與清理

驗證與清理使用者輸入至關重要。允許清單（allowlist）方式只接受安全字元與格式，例如帳號欄位僅接受英數字，特殊字元會被拒絕。
也可使用跳脫（escaping）技巧，對 SQL 語法可能解析的特殊字元進行編碼或中和，避免攻擊者改變查詢邏輯。

最小權限存取

限制使用者資料庫權限，只給予必要的操作範圍。即使帳號遭入侵，也能降低損害範圍。

網頁應用防火牆（WAF）與監控工具

WAF 可即時偵測並阻擋 SQL 注入攻擊，搭配其他監控工具可在應用程式層之外增加防護層。

定期安全測試

定期進行滲透測試與 SQL 注入測試案例，透過自動化工具與人工審查，及早發現漏洞，確保資安策略完整。

EDB Postgres AI 強化資料庫安全

EDB 提供一系列 PostgreSQL 工具與擴充功能，使防範 SQL 注入更簡單且有效，除了基本保護，還支援強化監控、稽核與安全策略。

EDB Postgres AI Advanced Server (EPAS)
內建安全擴充功能，加強 PostgreSQL 原生防護，包括更嚴格的密碼政策、角色管理與連線控管，降低未授權存取風險。

EDB Postgres AI Security Pack
提供進階稽核、細緻存取控制與安全策略，可在 SQL 執行前阻擋風險指令，協助維持合規。

PostgreSQL 擴充支援
支援多種提升安全的 PostgreSQL 擴充功能：

• Pgcrypto：資料加密與安全雜湊
• Pgaudit：詳細 SQL 稽核
• Plpgsql_check：PL/pgSQL 靜態程式碼分析
• Pg_stat_statements：追蹤 SQL 執行狀態與效能

EDB Postgres Insight
提供資料庫健康與效能監控，同時標示異常 SQL 行為，如登入失敗或非典型查詢，協助偵測注入攻擊。

EDB Postgres AI Enterprise Manager
自動健康檢查、警示與集中監控，協助管理者快速發現潛在安全問題，包括跨資料庫的 SQL 注入嘗試。

透過 EDB Postgres AI 專屬安全功能，組織可即時偵測與阻擋 SQL 注入，並維持合規與高流量環境下的韌性。

維持 SQL 注入防護韌性

防範 SQL 注入不是一次性的任務，而需持續努力。即使已有防護措施，程式碼變動、第三方互動與攻擊手法更新，都可能產生新漏洞。維持韌性包括：

• 定期更新：套用資料庫與相關軟體的安全補丁，避免因舊版本漏洞被攻擊。
• 稽核與 code review：檢查設定與程式碼，確保查詢一律使用參數化與安全綁定。
• 持續測試：透過自動化滲透測試提前找出可能的注入風險。
• 導入安全流程：將安全納入開發生命周期，如權限控管與建置時的自動掃描。
• 團隊教育：讓開發與 DBA 理解安全程式設計、參數綁定與輸入驗證的重要性。

本文翻譯自：What Is SQL Injection (SQLi), and How Do I Prevent Attacks?

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

本文將解析資料庫遷移的核心觀念，並分享如何透過有效的變更管理，讓遷移過程更順利、降低風險。

關於資料庫遷移

EDB 技術長 Julian Moffett 曾強調，企業並不是為了「好玩」而遷移資料庫，而是因為這是應用系統生態的一部分，也是核心業務資產。

資料庫遷移通常起因於基礎架構團隊希望降低成本，並引入更新、更具創新性的資料庫平台。

然而，在技術作業開始之前，首先必須明確定義目標、範圍、投資報酬率（ROI）以及時間規劃。

資料庫評估、結構修正（schema remediation）以及資料遷移只是技術層面的工作，而且僅占整個遷移流程的一小部分。

因此，資料庫遷移並非單純將舊資料庫換成新資料庫，而是一個涵蓋全面的變更管理（Change Management）專案，涉及策略規劃、團隊協作與流程調整。

找對關鍵夥伴

資料庫遷移除了是技術作業，也需要關鍵團隊的支持。

應用程式團隊必須從一開始就參與，確保遷移後應用能正常運作，必要時調整程式碼，避免原本的資料庫無法順利退役。

當然，財務團隊也很重要，他們要了解遷移的成本與價值。安全、合規以及各業務主管也是不可忽略的利害關係人。有時候直接取得 CTO 或 CIO 的支持，也可以讓整個遷移專案更順利推進！

設定明確目標

使用 SMART 方法（具體 Specific、可衡量 Measurable、可達 Achievable、相關 Relevant、有時限 Time-bound） 是管理利害關係人目標的好工具。透過設定清楚、可實現且可衡量的遷移目標，並確保與公司及各利害關係人的需求一致，可以有效避免潛在風險。

EDB 的流程與工具能協助企業達成目標，大幅減少重新編碼或重構 PL/SQL 或應用程式的工作量。同時，清楚估算工作量與成本，也是成功遷移的重要關鍵。

明確展現遷移的好處

有時候，團隊可能會因為手上有其他專案或業務交付壓力，而對資料庫遷移持保留態度。對未知的擔憂或認為遷移成本過高，也可能讓人猶豫不決。

因此，清楚說明遷移對企業、應用團隊以及所有參與者的效益非常重要！

為何需要遷移到 Postgres？

EDB 提供免費的 ROI 計算工具，幫助企業評估從 Oracle 遷移到 Postgres 可節省的成本。除了提升投資報酬率、降低費用之外，開發者體驗更佳、敏捷性提高。

對基礎架構團隊而言，能夠高度自動化部署資料庫，且不需人工干預，也是重要優勢。

另一個遷移的理由，是能吸引並留住人才。像 Postgres 這類現代技術，對新進畢業生具有吸引力，因為他們學校或實習時更可能接觸這些平台。

引入這些技術不僅有助於留住現有員工，也能吸引新人才，保留企業的知識資產，促進組織成長！

此外，EDB Postgres 的新分析與 AI 功能，也對開發者十分有吸引力。生成式 AI 的快速發展，正在改變整個產業格局。開發者與資料庫管理員對向量資料庫（vector database）非常感興趣，而 Postgres 本身也能作為向量資料庫運行，滿足這類需求。

資料庫遷移要有耐心

要成功完成資料庫遷移，不能只著眼於技術層面，還必須明確定義利害關係人、流程與遷移效益。

EDB 現場技術長 Julian Moffett 指出：「這部分的溝通絕對不能不足。你必須清楚向利害關係人說明遷移的價值、對公司重要性，以及對他們的核心好處。」

當被問到以他的遷移經驗，會給出哪些建議時，Julian 表示：「做好準備、動員團隊、持續溝通、建立並追蹤指標。要有耐心與毅力，一點一滴推進。這些步驟，最終才能真正釋放遷移帶來的效益。」

本文翻譯自：Navigating Legacy Database Migration: Mastering Change Management

想了解更多資訊，歡迎聯絡我們，或是加入歐立威 Line 好友！

近年來，資料湖倉（Lakehouse）已成為一種熱門選擇。它不僅成本效益高，也能高效管理與分析大量資料。湖倉中的資料來源多元：既可能來自營運系統（像是資料庫或企業資源規劃 ERP 系統，例如 SAP），也可能是即時產生的資料，能透過串流方式直接導入湖倉。

推薦閲讀：資料庫遷移指南：掌握變更管理一次看懂！

資料倉是什麼？

資料倉是一種高度整合、經過優化的資料存放與分析方式，主要用於關聯型資料。

相比資料湖，資料倉通常能提供更高品質的服務，但成本也更高。此外，資料倉的架構會帶來一些額外複雜性，例如需要透過擷取、轉換、載入的流程（ETL）把資料從資料湖移入資料倉，這也可能造成資料的可用性延遲。

資料湖倉跟資料湖是一樣的嗎？

兩者有相似之處。

資料湖就像一個大型水庫，可以存放各種結構化或非結構化資料，規模不受限制。而資料湖倉則在此基礎上加強了功能，它提供了元資料管理層，帶來資料管理工具與功能，並具備類似資料倉的能力。

為什麼需要資料湖倉？

資料湖倉能帶來多項優勢：

• 提供像資料湖一樣成本效益高、可擴展的資料存儲
• 擁有資料倉的交易一致性、低延遲查詢以及精細化存取控制
• 支援多種資料型態，包括結構化、半結構化和非結構化資料
• 互動式查詢回應速度快
• 不再需要在資料湖與資料倉之間維護獨立的 ETL 流程
• 能夠從其他系統或即時資料串流匯入資料，輔助資料探索、準備與優化

資料湖倉之所以能提供這些優勢，是因為它採用了優化的開放表格格式和開源標準，既能實現高效能分析，又保留資料湖般開放的架構。難怪越來越多企業選擇使用資料湖倉。

資料匯入方法

將資料導入資料湖主要有兩種方式：

以下方法為傳統資料湖常用的匯入方式，資料湖倉也可直接利用批次或即時資料進行分析。

（一）批次 ETL：

透過擷取、轉換、載入（ETL）的流程，先從來源系統抓取資料，再依需求進行轉換，最後批次載入資料湖。這種方式適合處理來自核心系統的大量營運資料。

（二）即時資料捕捉（CDC）：

另一種方式是透過變更資料捕捉（CDC）技術，即時監控資料變動，將最新資料持續導入資料湖。即時資料來源多元，例如透過 Kafka 等訊息總線傳送的物聯網（IoT）感測器資料或其他串流資料。

對於串流資料來源，資料會持續地直接匯入資料湖，這稱為串流資料匯入。即時匯入能讓企業及時分析快速變化的資料，與批次 ETL 處理的營運資料互為補充。資料一旦進入資料湖倉後，就可以進行分析，挖掘出有價值的洞察。

分析流程

分析工作通常包含以下步驟：

1. 資料探索：了解資料的品質、語意、結構等特性
2. 資料準備：進行資料清理、篩選、正規化以及去重
3. 資料優化：將資料轉換成適合高效分析的格式，例如欄式存儲或分析型資料表結構
4. 批次分析：對優化後的資料進行查詢或模型運算
5. 自動報告：將分析結果打包成排程報告，提供給使用者

資料湖雖然在大規模資料的成本效益存儲上表現出色，但對於某些進階分析需求仍有侷限，例如需要低延遲的即時儀表板互動查詢、連續資料匯入的交易一致性保障，或精細化的資料存取控制以符合法規與安全需求。

資料湖倉則能解決這些問題，將資料倉與資料湖的優點整合到單一、開放的架構中。作為一個統一的一站式解決方案，它兼具資料湖的成本效益與可擴展存儲能力，以及資料倉的高級分析功能和服務品質。

總結

總結來說，資料湖倉結合了資料湖與資料倉的優點，不僅能提供成本效益高、可擴展的資料存儲，還具備高級分析能力、低延遲查詢以及精細化存取控制。

它支援多種資料型態，能處理批次與即時資料流，並簡化資料整合流程，讓企業能更快速、靈活地探索、準備與分析資料。對希望同時兼顧效率與品質的企業而言，資料湖倉是一個完整、一站式的解決方案。

本文翻譯自：Unleashing AI with PostgreSQL: What is a Lakehouse?

想了解更多資訊，歡迎聯絡我們，或是加入歐立威 Line 好友！

PostgreSQL 開發團隊於 2023 年 9 月 24 日釋出了最新的 PostgreSQL 16 版開源資料庫，該版本在平行查詢、批次處理和邏輯複寫有顯著的效能提升，使其在處理大量數據時更為高效。此版本在 SQL/JSON 語法上提供更進階的支援，並提供更靈活的權限管理設定，讓使用者依據自身需求定義存取規則。另外，PostgreSQL 16 也優化了 VACUUM 和 ANALYZE 指令，並新增 pg_stat_io 系統表來加強效能監控。

PostgreSQL 16 五大升級

一、權限管理（Privilege Administration）

PostgreSQL 16 對權限管理進行深度優化與調整。在 PostgreSQL 15 的架構中，所有核心權限都集中於超級使用者，這種管理模式雖然對單一使用者或小型開發團隊來說直觀且高效，但當應用於大型組織，尤其在使用者眾多且各具特定權限需求的狀況下，這種集中化的權限管理方式往往不太靈活。

為了解決上述問題，Postgres 16 修改了 CREATEROLE 指令，讓使用者只能在具有 ADMIN OPTION 的角色下授予權限。這項更新讓系統管理員能夠更精確地分配的權限，另外，PostgreSQL 16 還加強了對 pg_hba.conf 和 pg_ident.conf 設定檔的管理，讓使用者對用戶和資料庫名稱進行正規表示法匹配，或用外部設定檔指定規則，增加管理效率。

PostgreSQL 16 還新增針對客戶端安全性的連線參數，例如透過 require_auth 讓客戶端指定想要的驗證方式，以及透過 sslrootcert=”system” 參數，讓 PostgreSQL 使用客戶端作業系統內建的憑證頒發機構。另外，此次改版也支援 Kerberos 的認證代理，讓  postgres_fdw 和 dblink 擴充套件使用憑證連接到其他受信服務。

二、邏輯複寫（Logical Replication）

PostgreSQL 16 對邏輯複寫進行多項性能優化。其中一項是為備援資料庫（Stand By）導入 Logical Decoding（邏輯解碼）功能，讓使用者在執行資料交易時，快照資料交易狀態並將其儲存於 WAL 檔，這種方式能夠有效降低使用檢查點（Check Point）的需求，而使用者能透過新的 pg_log_standby_snapshot() 函數來完成。

另外，PostgreSQL 16 利用平行查詢技術處理大型資料交易。當主節點正在執行資料交易時，系統能夠進行平行處理。基準測試（Benchmark Testing）顯示，PostgreSQL 16 與前幾個版本相比，執行 Bulk Insert 的效率提升了將近 40％。

PostgreSQL 16 還更新了其他邏輯複寫效能，包括初始化時的位元資料複製技術、對沒有主鍵（Primary Key）的表格，訂閱者（logical replication subscriber）可以使用 B－Tree 索引查詢資料列，從而取代序列掃描。在特定情境中使用者甚至能透過二進制格式增加初始表的同步效率。在資安方面，為確保資料的安全性與完整性，PostgreSQL 16  只允許資料表擁有者在執行邏輯複寫時使用 SELECT 和 DML 語法，這種更嚴格的權限管理策略要求訂閱者在複寫集（Replicatoin Set）中具有 SET ROLE 權限或具備超級用戶權限。

三、提升開發者使用體驗

PostgreSQL 16 新增了更多 SQL/JSON 標準語法，其中包括由 JSON 格式組成的建構子和述詞，例如：JSON_ARRAY()、JSON_ARRAYAGG() 以及 IS JSON。另外，PostgreSQL 16 還導入使用底線作為分隔符號（例如：5_432_000）和小數點以外的字符功能（例如：0x1538、0o12470 和 0b1010100111000）。

在 psql 工具方面，PostgreSQL 16 新增了許多指令。其中，bind 指令可以協助開發者準備參數化查詢，並透過該語法替代參數，例如：SELECT $1::int + $2::int bind 1 2 g。

另外，PostgreSQL 16 還內建對 ICU （國際統一編碼）的支援，這項功能會根據使用者的主機環境來確定文本排序方式，並允許使用者指定 ICU 排序規則。

 四、效能優化

PostgreSQL 16 透過優化查詢執行能力，大幅提升平行查詢結果。這次更新讓 FULL Join 和 RIGHT Join 能在並行模式下執行，而 aggregate group 和 parallel aggregate 指令則能提升 SQL 的運行效率。在 PostgreSQL 16 中 SELECT DISTINCT 查詢指令新增了增量排序（Incremental Sorting）功能，以提升資料處理效率。

另外，此次更新也改進了 Right 和 Outer 處理 Anti Join 的功能，讓使用者更容易查詢到資料表中不存在的資料列。

無論是單一或並行運算， 當使用 COPY 指令執行批次載入時，效能能夠提升高達 300% 。而 PostgreSQL 也為使用 libqp 的客戶端新增負載平衡機制，並對 Vacuum 語法進行優化，從而減少使用全表凍結（Full Table Freeze）的必要性，這代表未來 PostgreSQL 資料庫的高可用性和讀寫分離將更容易實現。

另外，PostgreSQL 16 在 x86 和 ARM 架構中使用 SIMD 增加 CPU 效能，因此在處理 ASCII 、 JSON 字串和陣列時能提高效能。

PostgreSQL 16 也同時進行了其他性能優化，例如對 RANGE 和 LIST 進行分區查詢以及允許使用者控制執行 ANALYZE / VACUUM 指令使用的 Shared Buffer 大小。

歐立威科技實測 Vacuum_buffer_usage_limit 

維運作業上，新加入的參數 vacuum_buffer_usage_limit ，提供管理者更具彈性的 Vacuum 作業資源使用控制。以下為歐立威科技進行的 Vacuum 效能控制測試結果（測試資源規格：2 Cores、記憶體 16 G、Shared_buffers 4 GB）。

【測試資源規格】

記憶體 2 Cores、16 G、Shared_buffers 4 GB

【完整結果整理】

• 表格大小 16 G時，參數設定 32 MB達到 Vacuum 最快之最小值。
• 表格大小 7974 MB時，參數設定 512 MB達到 Vacuum 最快之最小值。
• 表格大小 1595 MB時，因資料量太小，參數設定後 Vacuum 速度差異不大，實際效果可能取決於主機的實際狀況。

【觀察數據】

【測試結論】

1. Vacuum 操作的時間會受到表格數據量的影響，大表格需要更長的時間來完成 Vacuum。

2. 調整 vacuum_buffer_usage_limit 參數可以影響 Vacuum 的速度，但這並非絕對規則， 實際效果可能取決於主機的實際狀況。

3. 單一 Vacuum 作業使用 shared buffer 的上限約為 32 MB。這可能是 Vacuum 程式本身功能的瓶頸，有一個開口向上的曲線，形成一個 Vacuum 最快之最小值。

4. 建議將 vacuum_buffer_usage_limit 調整為 0 使 Vacuum 作業接近最快之最小值。

5. 此參數可以依 Session 進行設定，也可以直接在資料庫設定檔中指定參數大小。對於處理大表的 VACUUM FULL，可以透過 Session 的方式設定，以達到彈性調整的效果。

五、監控效能

PostgreSQL 16 對監控效能進行優化，並新增 pg_stat_io 視觀表，為使用者提供更完整的 IＯ 監測資訊，此外，它也能夠紀錄資料表上一次執行 Seq Scan 和 Index Scan 的時間，以及監測記憶體中資料行的搬移行為，並評估搬移機率。

在 pg_locks 視觀表中，PostgreSQL 16 加入了推測鎖定（Speculate Lock）的資訊，並導入能夠針對特殊後台設備進行分析與追蹤的功能。最後，PostgreSQL 16 也加入多種新的等待事件（Wait Event），讓 16 版的監控效能相較以往更加全面。

PostgreSQL 16 在 pg_stat_all_tables 系統表中新增用於紀錄表格或索引最後執行掃描的時間欄位。為了提高 auto_explain 的可讀性，PostgreSQL 16 會紀錄傳遞到參數化語句中的值。另外，此次改版優化了用於執行 pg_stat_statements 和 pg_stat_activity 的查詢追蹤演算法，以提高查詢的精確性。

歐立威科技持續追蹤與掌握 PostgreSQL 16 的最新動態。若有任何關於 PostgreSQL 應用、技術或建置的問題，歡迎立即諮詢，讓我們的專業團隊為您解答並提供支援。

本系列由 4 篇文章組成，分別為 ORACLE 與 POSTGRES 的比較(本篇)、資料庫評估、架構遷移、資料庫功能測試。歡迎閱讀系列中的其他文章，以了解完整的資料庫遷移步驟。

簡介

從 Oracle 轉移到 PostgreSQL 開源資料庫的企業數量正快速增長中，而這個完整的導引將提供用戶資料庫轉移過程所需的一切。

對於任何對轉移過程感到恐懼或懷疑的使用者來說，本篇將分析 PostgreSQL 資料庫系統對比 Oracle 的優勢以及採用 PostgreSQL 後可獲得的好處── 也就是降低成本、增加靈活性和客製化程度。

接下來，轉移過程將被分解成不同步驟，包含評估、模式轉移、功能測試、性能測試和數據轉移，並根據各階段進行逐步指導。

此外，兩種資料庫之間的關鍵系統性差異和不兼容之處被逐一列出，以幫助使用者避開常見錯誤，並權衡替代轉移方案，最終提出免費的有效轉移工具清單。

此導引除了提供給準備從 Oracle 遷移到 PostgreSQL 的用戶，也為正考慮引入 PostgreSQL 卻擔心轉移複雜性的 Oracle 用戶給予保證。 

資料庫遷移是什麼？

資料庫轉移是一種將軟體 (Definitions)、資料和儲存程序於平台，並改變應用程式的過程，過程中包含選擇、準備、擷取、轉換以及將資料應用於不同平台間。

使用者在轉移至 Postgres 的過程會經歷不同的階段，如挑選正確的架構、相容性檢核、改寫不相容的物件、功能和效能測試、資料轉移和轉移後檢查。

從 Oracle 轉移到 PostgreSQL 的益處為何  ?

下方列舉一些從 Oracle 遷移至 PostgreSQL 的益處

1. 撰寫應用程式
2. 認證
3. 可擴展性（Extensibility）
4. 語言
5. 在地化
6. 性能
7. 可擴展性（Scalability）

1.POSTGRESQL VS. ORACLE：撰寫應用程式

Oracle 和 PostgreSQL 都提供用於資料庫對話的 API 。受益於 PostgreSQL 的開源性質，開發者能夠使用 PostgreSQL 的原始碼進行二次開發。

2.POSTGRESQL VS. ORACLE：驗證

Oracle 使用內建認證系統， PostgreSQL 則依賴主機驗證，因此它支持廣泛的驗證方法。這是為何 Postgres 使用者更有彈性的驗證選擇，並可以選擇委託代執行過程。

3.POSTGRESQL VS. ORACLE：EXTENSIBILITY （可擴展性）

Oracle 套件多為專有性質，PostgreSQL 與之相比， 受益於其開源的特性和龐大社群支援，因此 Postgres 具有成千上萬的軟體套件供使用者選擇。

4.PostgreSQL vs. Oracle：語言

Oracle 採用內建程式語言 PL/SQL ，而 PostgreSQL 不僅容納 PL/pgSQL ，還擁有各種語言及延伸系統，並允許用戶創建額外的程序語言作為插件以及綁定更多程式語言。

5.POSTGRESQL VS. ORACLE：在地化

Oracle 提供全球化工具，包括開發套件和 unicode 編碼支持。

相較之下， PostgreSQL 採用內建的在地化服務系統，並提供自動字元編碼和校核功能。

6.POSTGRESQL VS. ORACLE：性能

PostgreSQL 能夠在單一讀取群集中創造無限的節點，並使讀取操作的成本趨近於零，這也讓用戶能對調整每個工作量。雖然使用者也可以在 Oracle上 這樣做，但卻需承擔每個節點的額外成本。

7.POSTGRESQL VS. ORACLE：SCALABILITY（可擴展性）

Oracle 有著優秀的垂直讀取可擴展性，然而 PostgreSQL 卻能於單一叢集中創建大量唯讀（Read Only）的 StandBy ，而這僅取決於用戶願意提供的資源量。

1. 成本：除了授權費用外，使用者還需為 Oracle 的分區功能和高可用性支付額外費用，這會導致鉅額成本。與之相比，基於Postgres 開源的特性，使用者能夠免費下載使用。
2. 靈活性：基於 PostgreSQL 開源的特性，使用者可以從包括 AWS 在內的公有雲端平台上取得 PostgreSQL ，消弭遭單一廠商壟斷的風險。
3. 可定制性：基於開源的特性，使用者能使用軟體套件和附加功能改善資料庫性能，而且大多套件是免費的。相較之下， Oracle 的使用者將為了類似功能付出鉅額成本。

因為資料在 RDBMS 之間進行轉移，而根據資料類型或是異質結構，整個過程將會是一個非常耗時的挑戰，因此使用者需用正確的工具來處理問題。

遵循以下步驟，問題將迎刃而解：

相比之下，採用 PostgreSQL 有什麼優勢？

簡而言之， PostgresQL 相較 Oracle 有以下七點特性：

1. 撰寫應用程式
2. 認證
3. 可擴展性（Extensibility）
4. 語言
5. 在地化
6. 性能
7. 可擴展性（Scalability）

1.POSTGRESQL VS. ORACLE：撰寫應用程式

Oracle 和 PostgreSQL 都提供用於資料庫對話的 API 。受益於 PostgreSQL 的開源性質，開發者能夠使用 PostgreSQL 的原始碼進行二次開發。

2.POSTGRESQL VS. ORACLE：驗證

Oracle 使用內建認證系統， PostgreSQL 則依賴主機驗證，因此它支持廣泛的驗證方法。這是為何 Postgres 使用者更有彈性的驗證選擇，並可以選擇委託代執行過程。

3.POSTGRESQL VS. ORACLE：EXTENSIBILITY （可擴展性）

Oracle 套件多為專有性質，PostgreSQL 與之相比， 受益於其開源的特性和龐大社群支援，因此 Postgres 具有成千上萬的軟體套件供使用者選擇。

4.PostgreSQL vs. Oracle：語言

Oracle 採用內建程式語言 PL/SQL ，而 PostgreSQL 不僅容納 PL/pgSQL ，還擁有各種語言及延伸系統，並允許用戶創建額外的程序語言作為插件以及綁定更多程式語言。

5.POSTGRESQL VS. ORACLE：在地化

Oracle 提供全球化工具，包括開發套件和 unicode 編碼支持。

相較之下， PostgreSQL 採用內建的在地化服務系統，並提供自動字元編碼和校核功能。

6.POSTGRESQL VS. ORACLE：性能

PostgreSQL 能夠在單一讀取群集中創造無限的節點，並使讀取操作的成本趨近於零，這也讓用戶能對調整每個工作量。雖然使用者也可以在 Oracle上 這樣做，但卻需承擔每個節點的額外成本。

7.POSTGRESQL VS. ORACLE：SCALABILITY（可擴展性）

Oracle 有著優秀的垂直讀取可擴展性，然而 PostgreSQL 卻能於單一叢集中創建大量唯讀（Read Only）的 StandBy ，而這僅取決於用戶願意提供的資源量。