學習如何在 Hetzner 上自建 PostgreSQL，搭配 Bytebase、DBHub、OpenBao 等工具，實現 Agent-friendly 的資料庫管理、權限控制與自動化部署，適合大量低流量 MVP 專案。
如果你正在開發大量實驗性、低流量的 MVP 專案，並且希望讓 AI Agent 能夠自主管理資料庫、執行遷移、動態取得憑證，那麼在 Hetzner 上自建 PostgreSQL 是一個值得考慮的方案。本文將說明如何設計一個以 Agent 為中心的資料庫控制平面，避免常見的陷阱，並推薦最適合的開源工具組合。
整體架構建議
將所有專案集中在同一台 Hetzner 伺服器上，使用單一 PostgreSQL 叢集，每個專案獨立一個 Database，而非獨立 Container 或 VM。這樣可以大幅降低管理成本，同時保持足夠的隔離性。
| 層級 | 建議方案 | 用途 |
|---|---|---|
| Infrastructure | Hetzner Cloud | 運行 PostgreSQL 與管理服務 |
| PostgreSQL 平台 | 原生 PostgreSQL；規模增加後改用 Pigsty | Database Engine、HA、PITR、監控 |
| Connection Pool | PgBouncer | 避免大量 Serverless／Agent Connection 壓垮 PostgreSQL |
| 人類管理介面 | Bytebase | 專案管理、Migration、SQL Review、權限與 MCP |
| Agent Database MCP | DBHub 或 Bytebase MCP | Schema 查詢、SQL 執行、Database 操作 |
| Schema Management | Prisma Migrate、Drizzle Kit 或 Atlas 三選一 | Schema as Code、Migration |
| Secret Management | OpenBao；較簡單可用 Infisical | 短效 PostgreSQL Credentials、API Token |
| Agent Queue | PGMQ 或 pg-boss | Agent 任務交換、重試、背景工作 |
| Backup | pgBackRest → Hetzner Object Storage／其他 S3 | PITR、異地備份、WAL Archive |
| Browser Automation | Browserbase + Stagehand | 只處理沒有 API 的 Web Console |
不要每個 MVP 建立一個 PostgreSQL Instance
你的情況是專案數量多、流量極低、多數處於實驗或 MVP 階段，主要問題是管理複雜度而非計算資源。最合理的模式是：
Hetzner Server
├── PostgreSQL Cluster: pg-lab
│ ├── Database: project_alpha
│ ├── Database: project_beta
│ ├── Database: project_gamma
│ └── Database: project_...
│
├── PgBouncer
├── Bytebase
├── DBHub
├── OpenBao
└── pgBackRest
每個專案使用獨立 Database，而非 Schema。Database-per-project 在權限、Migration、Connection 與 Backup 邏輯上更清楚。
建議至少拆成兩個 Cluster：pg-lab 負責所有實驗與開發，pg-prod-small 負責已上線但仍低流量的產品。真正產生營收的產品再升級到專屬 Cluster。
每個專案的權限模型
每個專案建立四種角色：
| Role | 權限 |
|---|---|
project_owner |
NOLOGIN，持有所有 Database Objects |
project_migrator |
只能執行該專案的 DDL／Migration |
project_runtime |
App 使用，只能 CRUD，不能修改 Schema |
project_readonly |
Agent 查詢與除錯，只能 SELECT |
範例：
CREATE ROLE project_alpha_owner NOLOGIN;
CREATE DATABASE project_alpha OWNER project_alpha_owner;
CREATE ROLE project_alpha_migrator LOGIN;
GRANT project_alpha_owner TO project_alpha_migrator;
CREATE ROLE project_alpha_runtime LOGIN;
CREATE ROLE project_alpha_readonly LOGIN;
REVOKE ALL ON DATABASE project_alpha FROM PUBLIC;
GRANT CONNECT ON DATABASE project_alpha
TO project_alpha_migrator, project_alpha_runtime, project_alpha_readonly;
不要讓任何 Coding Agent 使用 postgres、superuser、CREATEDB、CREATEROLE 或 BYPASSRLS。只有 Provisioning Service 能建立 Database 和 Role。
開源管理介面比較
| 工具 | 定位 | Agent／API 能力 | 適合度 |
|---|---|---|---|
| Bytebase | Database DevOps Control Plane | 原生 MCP、REST/gRPC API、Service Account、Terraform | 最高 |
| DBHub | 輕量 Database MCP Gateway | 原生 MCP、HTTP、Multi-connection | 最高，適合 Agent |
| Pigsty | 完整 PostgreSQL Distribution | Ansible、IaC、CLI | 正式環境再導入 |
| Autobase | 自建 PostgreSQL DBaaS | UI、CLI、GitOps、Ansible | 中高 |
| Coolify | Self-hosted PaaS | REST API、CLI | 適合 App，不宜當核心 DB Control Plane |
| pgAdmin | PostgreSQL 原生管理工具 | 幾乎沒有 Agent Control Plane | 人工 DBA 備用 |
| CloudBeaver | Web Database Client | 有 Web Connection 管理 | 查資料可以，Provisioning 不適合 |
| DbGate | 輕量 Web／Desktop DB Client | 無完整 Provisioning API | 輔助工具 |
| WhoDB | 輕量 Database Workspace | 內建 MCP、CLI、Web UI | DBHub 替代方案 |
Bytebase Community 目前免費、最多 20 位使用者與 10 個 Database Instances，包含 Project Management、Git-based Schema Version Control、Declarative Migration、SQL Review、Web SQL Editor 和 MCP Server。其限制是缺少完整 Approval Workflow、Custom Role、External Secret Manager 與正式 Audit Log。
Agent 應該怎麼連線
方案 A：DBHub（適合開發 Agent）
DBHub 的預設 MCP 只有 execute_sql 和 search_objects，Token 消耗低（約 1.4k Tokens），支援多個 Database Connection、Read-only Mode、Query Timeout、Row Limit、SSH Tunnel、SSL/TLS 與自訂 Parameterized SQL Tools。適合 Claude Code、Codex、Cursor、GitHub Copilot CLI 等。
注意：DBHub 的 HTTP Transport 沒有內建 Client Authentication，應只 Bind 到 127.0.0.1，並透過 Reverse Proxy、Firewall 或私有網路保護。
方案 B：Bytebase MCP（適合受管控的寫入）
Bytebase 支援 Claude Code、Codex、Copilot CLI、Gemini CLI 與 VS Code。Agent 透過 OAuth 登入後繼承該 Bytebase Account 的權限；Migration 和設定變更會歸屬到該身份。適合建立或查看 Project、查看 Database Schema、產生 Migration、執行受管理的 Schema Change。
應使用 Project-level Service Account，而非共用 Admin Account。
方案 C：Google MCP Toolbox（適合自訂 Tool API）
支援 PostgreSQL、Connection Pooling、Integrated Authentication、OpenTelemetry 與自訂 Toolset。適合將自由 SQL 收斂成特定能力，例如 create_customer、get_order 等固定 Tool。
實際建議
- 開發、探索、Debug：DBHub read-only / limited write
- Schema Migration：Bytebase MCP + Migration Pipeline
- 正式 App Agent：Google MCP Toolbox 或自訂 MCP，只暴露固定 Tool
不同 Agent 之間怎麼互動
MCP 解決的是 Agent 如何操作 Database 或 Tool，本身不是 Agent-to-Agent Message Queue。需要另外建立 Queue。
低流量情境：直接使用 PostgreSQL Queue
- PGMQ：輕量 Queue，可作為 Extension 或 SQL-only 安裝，不需要另外維護 Redis、RabbitMQ。建議資料模型：
agent_tasks、agent_runs、agent_events、agent_artifacts、agent_leases。 - pg-boss：Node.js 專案可用，提供 Retry、Exponential Backoff、Dead Letter Queue、Cron、Priority Queue、Exactly-once Job Delivery。
- Temporal：只有當工作流程包含長時間執行、多步驟 Browser Automation、Human Approval、多次 Retry 或外部 API Side Effect 時才需要導入。
Agent 如何自動建立 Database、欄位與 Credentials
錯誤流程
Agent 透過 Browserbase 登入 pgAdmin / Coolify，點擊建立 Database，複製 Password，寫入 .env。問題：UI 改版就失效、難以保證 Idempotency、Password 容易外洩。
正確流程
建立一個小型 Provisioning Service：
POST /v1/projects
POST /v1/projects/{id}/databases
POST /v1/projects/{id}/credentials
DELETE /v1/projects/{id}
POST /v1/projects/{id}/archive
Agent 只提交：
{
"project": "customer-portal",
"environment": "development",
"region": "sin",
"extensions": ["pgcrypto", "vector"],
"orm": "prisma"
}
Provisioning Service 負責：
- 驗證 Project Name
- 建立 Database
- 建立 Owner、Migrator、Runtime、Readonly Roles
- 建立 Bytebase Project
- 將 Database 加入 Bytebase
- 建立 DBHub Connection Profile
- 從 OpenBao 產生短效 Credentials
- 將 Secret Reference 寫入 Infisical、GitHub Actions 或部署平台
- 回傳 Database Metadata，不直接回傳永久 Password
回傳內容範例：
{
"database": "customer_portal_dev",
"host": "pgbouncer.internal",
"port": 6432,
"secret_ref": "openbao://database/creds/customer-portal-runtime",
"bytebase_project": "customer-portal"
}
欄位與 Schema 應由 Migration 建立
Agent 不應直接透過 Browser UI 建欄位。正確流程：
Agent 修改 ORM Schema / schema.sql
↓
產生 Migration
↓
Lint
↓
在 Temporary Database 測試
↓
Bytebase Review
↓
Development 自動套用
↓
Production 人工或 Policy Approval
Migration Tool 選擇
| 開發模式 | 建議 |
|---|---|
| Prisma 專案 | Prisma Migrate |
| Drizzle 專案 | Drizzle Kit |
| 多語言、多 ORM | Atlas |
| 已有大量 SQL Migration | Bytebase 直接管理 |
| 大型正式產品、零停機要求 | pgroll 或專門 Online Migration 流程 |
不要同時讓 Prisma Migrate 和 Atlas 都成為 Migration Source of Truth。應選擇一個產生 Migration，Bytebase 只負責審查與執行。
Credentials 和 Token 如何處理
Plain PostgreSQL 沒有 Supabase 那類 API Token。若需要 REST API Token，必須另外部署 PostgREST / Hasura / 自建 API + JWT Issuer。
最佳方案是使用 OpenBao 動態 Credentials：Agent 啟動時使用 OIDC 向 OpenBao 認證，取得 30 分鐘有效的 project_migrator，執行 Migration 後憑證自動撤銷。Agent 不需要看到長效 Database Password。
較容易使用的替代方案是 Infisical，支援 Machine Identity、OIDC 與多種 SDK，並已推出 Credential Broker。
Browserbase 應該扮演什麼角色
Browserbase 適合：
- 第三方服務完全沒有 API
- 必須登入 SaaS 後台產生 API Key
- 需要建立 OAuth App
- 需要操作只有 Web UI 的 Vendor Console
- 需要人工介入處理 2FA 或異常頁面
使用 Browserbase 時：
- Context 只能綁定單一 Vendor 或單一權限範圍
- 不要建立「萬用 Browser Profile」
- API Key 建立後立即送進 Secret Broker
- 不得讓 LLM 在輸出中回傳 Secret
- 建立 API Key 的 Browser Workflow 必須有 Idempotency Check
- Token 建立與撤銷都必須記錄 Resource ID
- Browser Agent 不得同時擁有 Database Superuser
Coolify 是否適合
Coolify 可以一鍵建立 PostgreSQL、設定 SSL、S3 Backup，但目前不適合作為核心 Database Control Plane，原因包括：
- PostgreSQL API 曾出現 Resource 建立成功但 Container 沒有實際啟動的問題
- 多 Destination 環境曾出現 Database 被建立到錯誤 Destination 的問題
- Shared PostgreSQL Instance 自動建立多個 Database 的 API／Init Script 支援仍不完整
- Backup 主要是完整
pg_dump，不是完整 WAL-based PITR 平台
定位應是：Coolify 負責 App、Worker、MCP Server、Bytebase、OpenBao 部署；Pigsty / 原生 PostgreSQL 負責 Database；Bytebase 負責 Database Project 與 Migration Control。
Pigsty 和 Autobase 是否需要
Pigsty 已整合 Patroni HA、etcd、PgBouncer、HAProxy、pgBackRest、PITR、Prometheus、Grafana、Alerting、S3/MinIO Backup。適合有數個重要正式產品、需要 Replica、自動 Failover 與完整 Monitoring 的場景。不適合一開始就導入，因為你的主要問題是「很多低流量 Database」，不是 HA Cluster。
Autobase 更像真正的 Self-hosted PostgreSQL DBaaS，支援 UI、CLI、GitOps、Automated Failover、Backup/Restore、Upgrade、Scaling。適合管理少量正式 PostgreSQL Cluster，不如 Bytebase 適合把上百個小 Database 分組成 Agent Projects。
備份與可靠性
Hetzner Cloud VM 的 SLA 是 99.9%，單一 VM 仍可能出現每月數十分鐘等級的允許停機。VM Snapshot 不能取代 PostgreSQL-aware Backup。建議使用 pgBackRest 支援 Full、Differential、Incremental Backup、WAL Archive、Point-in-Time Recovery、S3-compatible Object Storage、Encryption、Checksum Validation 與 Parallel Backup/Restore。
最低備份設計：
- 每天 Full / Differential Backup
- 持續 WAL Archive
- 保留 14～30 天 PITR
- 備份到不同 Hetzner Location 或另一個 Provider
- 每月執行自動 Restore Test
Hetzner 成本與規格
2026 年 6 月 15 日後，Hetzner 已大幅調整 Cloud Server 價格。目前價格（不含 VAT 與 IPv4）：
| Region | CPX22 | CPX32 |
|---|---|---|
| Germany／Finland | €19.49／月 | €35.49／月 |
| Singapore | €26.49／月 | €48.99／月 |
CPX22 為 2 vCPU、4 GB RAM、80 GB NVMe；CPX32 為 4 vCPU、8 GB RAM、160 GB NVMe。
建議規格
- 最低可用：CPX22，只適合 PostgreSQL + PgBouncer + 少量 Bytebase/DBHub，不安裝完整 Grafana、OpenBao、Pigsty Stack。
- 建議起始規格：CPX32，適合數十個低流量 Database、PostgreSQL、PgBouncer、Bytebase、DBHub、OpenBao、基本 Monitoring。
Region 選擇：若 App 部署在 Hetzner Singapore、Vercel Singapore、Cloudflare Workers APAC 或 Fly.io Singapore，Database 應放 Singapore。若 App 和 Background Worker 都部署在德國，且終端使用者不直接連 Database，Database 放德國仍可行。
最終推薦組合
現階段
Hetzner Singapore CPX32
Ubuntu LTS
PostgreSQL
PgBouncer
Bytebase Community
DBHub
OpenBao
pgBackRest
PGMQ
Caddy
Private Network / WireGuard / Tailscale
Agent 權限
- Architect Agent：Bytebase Project-level Service Account，可產生 Migration，不直接持有 Superuser
- Coding Agent：DBHub read-only + Development runtime role
- Migration Agent：短效 project_migrator Credential
- Review Agent：Readonly Schema、Migration Diff、Query Plan
- Production Runtime：固定低權限 runtime role
Provisioning 流程
Agent 建立專案
↓
呼叫 Provisioning API
↓
建立 Database + Roles
↓
建立 Bytebase Project
↓
建立 Secret Policy
↓
產生 DBHub / MCP Profile
↓
建立 Migration Directory
↓
回傳 Metadata 與 Secret Reference
不建議
- Coolify 每個專案一個 PostgreSQL Container
- Browserbase 操作 pgAdmin 建 Database
- 所有 Agent 共用一組 postgres Password
- 把 Connection String 放進 CLAUDE.md
- 公開 5432
- 只使用 Hetzner Snapshot
- 所有 MVP 與正式產品共用一個 Superuser
結論
Hetzner 自建 PostgreSQL 值得採用，但核心不是「安裝一個好看的 PostgreSQL UI」，而是建立一個 Agent-friendly Database Control Plane。最符合你的組合是：Bytebase 負責專案與 Migration 治理，DBHub 負責低 Token MCP 連線，OpenBao 負責短效 Credentials，PgBouncer 負責大量 Agent／Serverless Connection，pgBackRest 負責 PITR。Pigsty 等到有數個重要正式產品、需要 HA 與 Replica 時再導入。Coolify 可負責部署這些服務，但不應成為核心 PostgreSQL 管理層。Browserbase 只處理沒有 API 的外部 Web Console，不負責日常 Database Provisioning。