pgcli

扩展目录

Mon, 01 Jan 0001 00:00:00 +0000

本页列出基础镜像中所有内置扩展。使用示例请参见常用扩展。

内置扩展（45 个）

这些扩展已包含在 PostgreSQL 基础镜像中，无需镜像构建或 pg extension install。直接运行 CREATE EXTENSION 即可启用。

意见反馈

Mon, 01 Jan 0001 00:00:00 +0000

pgcli 通过 GitHub 和邮箱收集反馈。

报告问题或提出功能建议——在 mars-base/pgcli/issues 提交 issue，附上 pg version 输出与复现步骤。
邮件反馈——不方便公开留言时，写信到 dw_wang126@126.com。

PgBouncer

Mon, 01 Jan 0001 00:00:00 +0000

PgBouncer 是轻量级的 PostgreSQL 连接池。作为 pgcli 插件，它以容器形式运行在一个或多个 PostgreSQL 实例前面，在大量短生命周期客户端会话之间复用服务端连接 —— 默认使用事务级池化。

常用扩展

Mon, 01 Jan 0001 00:00:00 +0000

最常用 PostgreSQL 扩展的使用示例，已在 PG 18 + pgcli 环境下测试通过。

性能与监控

扩展	安装	描述
`pg_stat_statements`	`pg extension install pg_stat_statements`	SQL 性能分析。生产环境必备。
`pg_repack`	`pg extension install pg_repack`	在线表重组，回收膨胀空间。
`pg_prewarm`	`pg extension install pg_prewarm`	重启后预加载表数据。

# 一次性安装所有扩展
pg extension install pg_stat_statements,pg_repack,pg_prewarm --auto-restart

# 查找 top 5 慢查询
pg exec "SELECT query, calls, total_exec_time::numeric(10,2) AS ms
         FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;"

# 重组膨胀表
pg exec -- pg_repack -U admin -d default_db -t my_table --no-superuser-check

# 预热表
pg exec "SELECT pg_prewarm('my_table');"

数据类型与标识符

扩展	安装	描述
`uuid-ossp`	内置	UUID 生成（v1/v3/v5）。PG 18 已内置 `gen_random_uuid()` (v4) 和 `uuidv7()` (v7)——无需安装扩展。
`hstore`	内置	键值对存储。
`citext`	内置	不区分大小写的文本。`Foo` = `foo`。

# UUID 生成（PG 18 内置——无需安装扩展）
pg exec "SELECT gen_random_uuid();"  # v4 随机 UUID（PG 13 起内置）
pg exec "SELECT uuidv7();"           # v7 时间有序 UUID（PG 18 新增）

# uuid-ossp 扩展——仅在需要 v1/v3/v5 UUID 时安装
pg exec "CREATE EXTENSION IF NOT EXISTS \"uuid-ossp\";"
pg exec "SELECT uuid_generate_v1();"  # v1 时间戳 + MAC 地址
pg exec "SELECT uuid_generate_v3(uuid_ns_url(), 'https://example.com');"  # v3 基于 MD5
pg exec "SELECT uuid_generate_v5(uuid_ns_url(), 'https://example.com');"  # v5 基于 SHA-1

# 键值存储
pg exec "SELECT 'theme => dark, lang => en'::hstore -> 'theme';"
# 返回: dark

# 不区分大小写匹配
pg exec "CREATE TABLE users (email citext);
         INSERT INTO users VALUES ('Alice@Example.COM');
         SELECT * FROM users WHERE email = 'alice@example.com';"

搜索与文本

扩展	安装	描述
`pg_trgm`	内置	三元组相似性，用于模糊搜索和自动补全。
`unaccent`	内置	去除重音，用于灵活的国际化文本搜索。

# 模糊搜索
pg exec "SELECT name, similarity(name, 'John') FROM users
         ORDER BY similarity(name, 'John') DESC LIMIT 5;"

# 创建三元组索引加速模糊搜索
pg exec "CREATE INDEX users_name_trgm_idx ON users USING gin (name gin_trgm_ops);"

# 去除重音
pg exec "SELECT unaccent('Crème Brûlée');"  -- 返回 'Creme Brulee'

# 组合使用实现不区分重音的模糊搜索
pg exec "SELECT name FROM users WHERE name % unaccent('Creme Brulee');"

安全与加密

扩展	安装	描述
`pgcrypto`	内置	哈希、加密/解密、随机数生成。
`pgaudit`	`pg extension install pgaudit`	审计日志。合规（GDPR、HIPAA、SOX）必需。

# 使用 bcrypt 哈希密码
pg exec "SELECT crypt('my_password', gen_salt('bf'));"

# 验证密码
pg exec "SELECT (crypt('my_password', stored_hash) = stored_hash);"

# 对称加密/解密
pg exec "SELECT pgp_sym_decrypt(pgp_sym_encrypt('secret', 'key'), 'key');"

# 启用特定操作的审计日志
pg exec "SET pgaudit.log = 'read, ddl';"

地理空间

扩展	安装	描述
`postgis`	`pg extension install postgis`	完整空间数据库：几何类型、空间索引、距离/面积计算。

pg extension install postgis --auto-restart

# 创建包含空间数据的表
pg exec "CREATE TABLE places (id serial, name text, geom geometry(Point, 4326));"
pg exec "INSERT INTO places (name, geom) VALUES
         ('San Francisco', ST_MakePoint(-122.4, 37.8)),
         ('London', ST_MakePoint(-0.1276, 51.5074));"

# 查找 5km 范围内的地点
pg exec "SELECT name FROM places
         WHERE ST_DWithin(geom, ST_MakePoint(-122.4, 37.8)::geography, 5000);"

# 计算两个城市间的距离（米）
pg exec "SELECT ST_Distance(
           ST_MakePoint(-74.006, 40.7128)::geography,
           ST_MakePoint(-0.1276, 51.5074)::geography);"

AI 与向量搜索

扩展	安装	描述
`pgvector`	`pg extension install vector`	存储和搜索嵌入向量。AI 应用标准。

pg extension install vector --auto-restart

# 创建带向量列的表
pg exec "CREATE TABLE items (id serial PRIMARY KEY, embedding vector(3));"
pg exec "INSERT INTO items (embedding) VALUES ('[1,2,3]'), ('[4,5,6]'), ('[7,8,9]');"

# 查找最近邻（欧几里得距离）
pg exec "SELECT id FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;"

# 创建 IVFFlat 索引加速近似搜索
pg exec "CREATE INDEX items_embedding_idx ON items USING ivfflat (embedding vector_l2_ops);"

时序数据

扩展	安装	描述
`timescaledb`	`pg extension install timescaledb`	优化的时序存储，支持超级表。

pg extension install timescaledb --auto-restart

# 创建超级表
pg exec "CREATE TABLE sensor (time timestamptz NOT NULL, value float);
         SELECT create_hypertable('sensor', 'time');"

# 时间桶聚合
pg exec "SELECT time_bucket('1 hour', time) AS bucket, avg(value)
         FROM sensor GROUP BY bucket ORDER BY bucket;"

定时任务与分布式

扩展	安装	描述
`pg_cron`	`pg extension install pg_cron`	Cron 定时任务调度器。pgcli 自动配置。
`citus`	`pg extension install citus`	分布式 PostgreSQL，支持分片。

pg extension install pg_cron --auto-restart

# 调度每日清理任务（午夜运行）
pg exec "SELECT cron.schedule('cleanup', '0 0 * * *',
         'DELETE FROM logs WHERE created_at < now() - interval ''30 days''');"

# 列出已调度的任务
pg exec "SELECT jobid, schedule, command FROM cron.job;"

# 取消调度
pg exec "SELECT cron.unschedule('cleanup');"

外部数据

扩展	安装	描述
`postgres_fdw`	内置	将外部 PostgreSQL 服务器作为本地表查询。
`pg_duckdb`	`pg extension install pg_duckdb`	嵌入式 DuckDB 分析引擎。读取 Parquet/CSV，OLAP 查询加速。

# 创建外部服务器
pg exec "CREATE SERVER remote FOREIGN DATA WRAPPER postgres_fdw
         OPTIONS (host '10.0.0.2', port '5432', dbname 'analytics');"

# 创建用户映射
pg exec "CREATE USER MAPPING FOR current_user SERVER remote
         OPTIONS (user 'reader', password 'secret');"

# 导入远程 schema 作为外部表
pg exec "IMPORT FOREIGN SCHEMA public FROM SERVER remote INTO remote_schema;"

# 像查询本地表一样查询远程数据
pg exec "SELECT * FROM remote_schema.events LIMIT 10;"

pg extension install pg_duckdb --auto-restart

# 在 DuckDB 中执行 SQL —— duckdb.query 是表函数（必须在 FROM 子句中使用）
pg exec "SELECT * FROM duckdb.query(\$\$ SELECT 42 AS answer, 'hello' AS msg \$\$);"

# 将表导出为 Parquet 文件
pg exec "COPY my_table TO '/tmp/my_table.parquet' (FORMAT 'parquet');"

# 直接读取 Parquet/CSV 文件
pg exec "SELECT * FROM duckdb.query(\$\$
         SELECT * FROM read_parquet('/tmp/my_table.parquet') WHERE id > 2 \$\$);"

# 将整个查询下推到 DuckDB 执行（OLAP 加速）
pg exec "SET duckdb.force_execution = true;
         SELECT category, sum(amount) FROM sales GROUP BY category;"

# 纯 DuckDB SQL（完全绕过 PostgreSQL 规划器）
pg exec "SELECT * FROM duckdb.raw_query(\$\$ SELECT range AS n FROM range(1, 6) \$\$);"

# --- 从 S3 / MinIO 读取文件（无需复制文件） ---

# 先创建 S3 secret（use_ssl 是文本类型：'true'/'false'）
pg exec "SELECT duckdb.create_simple_secret('S3', '<access_key>', '<secret_key>',
         '', 'us-east-1', 'path', '', 'minio.example.com:9000',
         's3://bucket', '', 'false');"

# 直接查询 bucket 中的 CSV
pg exec "SELECT * FROM duckdb.query(\$\$
         SELECT category, count(*) AS cnt, sum(sales) AS total_sales
         FROM read_csv('s3://bucket/products.csv', auto_detect=true)
         GROUP BY category ORDER BY total_sales DESC \$\$);"

兼容性说明

扩展	PG 18 状态	备注
`pgml`	不可用	仅支持 PG 14-17（无 PG 18 包）
`uuid-ossp`	部分需要	PG 18 内置：`gen_random_uuid()` (v4)、`uuidv7()` (v7)。扩展仅在需要 v1/v3/v5 时安装

技术支持

Mon, 01 Jan 0001 00:00:00 +0000

安装、实例管理、备份、副本、HA 集群等任何问题，都可以直接联系 pgcli 维护者。

微信

用微信扫描下方二维码添加好友，好友申请请备注技术咨询：

Etcd

Mon, 01 Jan 0001 00:00:00 +0000

etcd 是一个分布式键值存储。pgcli 可以将一个或多个 etcd 成员作为独立的顶层 addon 运行 —— 它是共享基础设施，而非绑定某个实例的 sidecar。常见用途是为 PostgreSQL 高可用栈充当 DCS（Distributed Concurrent Store），或作为通用的配置 / 锁服务。

付费订阅

Mon, 01 Jan 0001 00:00:00 +0000

pgcli 本身免费开源（Apache 2.0）。付费订阅可获得优先响应、生产部署协助与功能建议通道。

PgDog

Mon, 01 Jan 0001 00:00:00 +0000

PgDog 是一个用 Rust 编写的高性能 Postgres 代理（PgCat 的继任者）。它提供连接池化、跨副本的读写负载均衡，以及水平分片，位于一个或多个 PostgreSQL 后端之前。pgcli 可将 PgDog 作为独立的顶层插件运行：它是共享基础设施，而非依附某个实例的 sidecar。

Garage

Mon, 01 Jan 0001 00:00:00 +0000

Garage 是 Deuxfleurs 出品的 Rust、AGPLv3 S3 兼容对象存储重实现，为小规模自建和异地分布式集群设计。pgcli 将其作为独立的顶层插件运行，CLI 表面与 minio、silo、rustfs 一致（install、list、logs、autostart、password），但其运行时模型在四个方面与三者都不同，这也决定了本页的写法：

Patroni 高可用

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 是 PostgreSQL 高可用的事实标准：它管理每个 postmaster 的生命周期、在成员间流式复制，并在 leader 失联时执行 自动故障切换。pgcli 将 Patroni 作为独立的模式暴露 —— pg ha —— 而不是把它揉进普通的 pg 实例管理路径。

Patroni 动态配置

Mon, 01 Jan 0001 00:00:00 +0000

这些参数存储在 DCS（etcd）的 /service/<scope>/config 下，应用于集群的所有成员。使用 pg ha edit-config 修改：

pg ha edit-config app -- -s loop_wait=5
pg ha edit-config app -- -s 'postgresql.parameters.max_connections=200'
pg ha edit-config app --show          # 查看当前配置

参考：Patroni 官方文档、 Pigsty 动态配置。

PostgREST

Mon, 01 Jan 0001 00:00:00 +0000

PostgREST 是一个单进程、无状态的 Web 服务器，把一个 PostgreSQL schema 直接变成 RESTful API。作为 pgcli 插件，它是贴在任意 PG 端点前面的一个容器——没有数据目录、没有渲染出的配置文件，全部通过 PGRST_* 环境变量配置。

SeaweedFS

Mon, 01 Jan 0001 00:00:00 +0000

SeaweedFS 是一个 Go 语言、Apache-2.0 的 S3 兼容对象存储，其标志性特征是以 volume 粒度管理磁盘：数据被切成固定大小的 volume（.vol 文件），由 master 在各 volume 服务器之间放置，从而获得 O(1) 读取和廉价的小文件存储。pgcli 将其作为独立的顶层插件运行，CLI 表面与 garage、minio、silo、 rustfs 一致（install、list、logs、autostart、password、 pg mc），但其运行时模型在四个方面与四者都不同，这也决定了本页的写法：

Patroni REST API

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 在每个成员上暴露一个 HTTP REST API，提供健康检查端点（供负载均衡器和 Kubernetes 探针使用）、监控数据（含 Prometheus 指标）以及集群管理操作。

参考：Patroni 官方文档、 Pigsty REST API。

查找 REST API

每个成员的 REST API 端口由 pgcli 自动分配，存储在 pg.yaml 的 addons.patroni.<scope>.members.<name>.restapi_port 下。端口也写入渲染后的 patroni.yml 的 restapi.connect_address。

RustFS

Mon, 01 Jan 0001 00:00:00 +0000

rustfs 是 Rust 重新实现的 S3 兼容对象存储：同样的 S3 API、Web 控制台、纠删码多盘/多节点布局——但运行时模型与 MinIO/silo 完全不同。pgcli 将其作为独立的顶层插件运行，CLI 表面与 minio、silo 一致（install、TLS、BYO 证书、 drives、logs、autostart），共用同一个端口池；但有三点决定了本页的写法：

HA 集群扩展安装

Mon, 01 Jan 0001 00:00:00 +0000

在 Patroni 管理的 HA 集群中安装 PostgreSQL 扩展，与单节点实例有本质区别。本页解释原因，并介绍 pg ha extension 命令子树。

为什么不能用 `pg extension install`？

单节点流程（pg extension install <instance> <ext>）的工作方式是：

HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy 是 Patroni 官方文档推荐放在集群前面的负载均衡器：客户端只连一个稳定地址，HAProxy 对各成员的 REST API 做健康检查，把写请求路由到当前 leader（读写分离模式下，读请求路由到 replica）。pgcli 将其作为 独立的顶层插件运行——共享的路由基础设施，而非实例级 sidecar——镜像固定为官方 haproxy:3.2.23-alpine。

Silo

Mon, 01 Jan 0001 00:00:00 +0000

silo 是 Pigsty 社区维护的 MinIO 分支：S3 兼容对象存储、内置 Web 控制台，并完整保留了 MinIO 的对外契约——S3 API、MINIO_* 环境变量、server /data --address :9000 --console-address :9001 命令行、 --certs-dir 目录布局、以及纠删码集群模式。pgcli 将其作为独立的顶层插件 运行，功能面与 minio 插件完全一致——install、TLS、BYO 证书、分布式模式、logs、autostart 一一对应。如果你跟随 Pigsty 的发布节奏就选 silo；两者可以在同一台主机并存（共用一个端口池，统一游标分配，不会冲突）。

MinIO

Mon, 01 Jan 0001 00:00:00 +0000

MinIO 是 S3 兼容的对象存储。pgcli 将其作为独立的顶层插件 运行——共享基础设施，而非实例级 sidecar——带 Web 控制台。默认采用单机（single-node）模式，也支持跨主机的分布式集群模式（见下文分布式 / 集群模式）。两种模式下它都是通用对象存储。 silo——Pigsty 的 MinIO 分支，保持线路兼容——作为同级插件提供，功能面完全一致；两者共用一个端口池，可在同一主机并存。

Patroni 集群备份

Mon, 01 Jan 0001 00:00:00 +0000

本页给出 Patroni HA 集群备份的完整操作流程：从 pg backup setup 打通备份基础设施，到 pg ha snapshot 做全量/增量/差异备份，再到一个运行态坑——副本 Replay LSN 卡住导致 pg ha status 显示成员 LSN 不一致时，如何用 patronictl reinit 拉回。命令与前置机制的参考细节见 Patroni HA 与备份；本页把它们串成一条能照着跑完的路径。

Redis

Mon, 01 Jan 0001 00:00:00 +0000

Redis 是应用需要缓存、会话后端、排行榜（有序集合）或原子计数时最常选的内存键值存储。pgcli 将其作为独立的顶层插件运行，CLI 表面与对象存储一致（install / start / stop / logs / autostart / remove），全部通过 pg.yaml 管理。

Patroni 集群恢复

Mon, 01 Jan 0001 00:00:00 +0000

本页是 Patroni 集群备份 的恢复侧姊妹页。集群一旦有了带 WAL 归档的 stanza（pg backup setup + pg ha snapshot），pg ha restore 就能把整个集群回到某个时间点——它是单实例 pg restore 的 Patroni 集群对应物。本页讲清机制（为什么集群 PITR 不是简单跑一次 pgbackrest restore）、关于 leader 所在主机的安全性预检、端到端操作流程，以及恢复之后必须做的重新基线步骤。命令 / flag 细节同时见恢复 → Patroni 集群；本页把它们串成一条可照着跑的流程。

Predixy

Mon, 01 Jan 0001 00:00:00 +0000

Predixy 是一个高性能 Redis 协议代理。 pgcli 把它做成一个独立的顶层插件：它接住一个 Redis 原生集群（3 个以上节点、16384 个 slot、MOVED 重定向），再把它交回应用侧——形式是 一个普通的 redis:// 端点。客户端不需要懂集群：不加 -c、不处理重定向，连上就能读写。

HA Exec / psql

Mon, 01 Jan 0001 00:00:00 +0000

pg ha exec 和 pg ha psql 是对 Patroni 集群直接跑 SQL 的方式。它们是单实例 pg exec / pg psql 的集群对应物：你只给一个 scope，工具负责解析目标并连上去。不用手拼 --dsn、不用 podman exec 钻进成员容器，而且因为走的是普通 TCP，另一台主机上的 leader 或副本和本机成员一样可达。

pgAdmin 4

Mon, 01 Jan 0001 00:00:00 +0000

pgAdmin 4 是 PostgreSQL 的官方 Web 管理界面——在浏览器里浏览 schema、执行 SQL、观察服务器状态。pgcli 将其作为独立的顶层插件运行，CLI 表面与其他 web/infra 插件一致（install / start / stop / logs / autostart / remove），全部通过 pg.yaml 管理。

Nginx

Mon, 01 Jan 0001 00:00:00 +0000

nginx 是 HTTP 反向代理，用于前置多个 Web 服务——仪表盘、API、管理面板——通过基于路径的路由和可选 TLS 终止。pgcli 将其作为独立的顶层插件运行，CLI 表面与其他 web/infra 插件一致（install / start / stop / logs / autostart / remove），全部通过 pg.yaml 管理。

示例：HA 集群 + 自签 CA 的 MinIO

Mon, 01 Jan 0001 00:00:00 +0000

这是一页实操示例，每一步都真实跑通并验证过：创建 Patroni HA 集群，架一台对外服务自带域名证书的 MinIO 插件（这里用我们自己造的自签 CA——与公共 CA、企业 CA 证书同一种形态，只是没去买），并把集群的 pgBackRest 备份与 WAL 归档指向它。下面每条命令都是实跑过的命令；只有主机名、端口、密码和证书材料做了泛化处理。

Grafana

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install grafana 以受管容器方式运行 Grafana——开源可观测性面板——直接跑官方上游镜像。与 pgAdmin 一样，它是顶层插件：不依附于任何单个 PostgreSQL 实例，也不会自动前置它们——数据源和仪表盘都在 Web UI 里自己添加。v1 是纯 Web UI：配置只经环境变量（GF_*）交付，不挂载任何 datasource/dashboard 的 provisioning。

生成证书 —— pg cert

Mon, 01 Jan 0001 00:00:00 +0000

pg cert 签发一张自签证书——SubjectAltNames 覆盖你要求的任意域名 / IP 组合——适用于任何不想走 CA 又需要 TLS 的场合：开发或测试服务器、内部端点、客户端归你可控的服务。它写出的就是一张普通的 TLS 服务端叶证书，哪里都能用。

Prometheus

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install prometheus 以受管容器方式运行 Prometheus——指标采集与告警后端——直接跑官方 docker.io/prom/prometheus 镜像。与 Grafana 一样，它是顶层插件：不前置某个具体实例（它抓很多端点），也不依附于任何一个。二者是天然搭档——Prometheus 负责采集与存储、Grafana 负责可视化——且生命周期形状完全一致（单容器、Linux 上宿主网络、各自端口池里的一个 web 端口、持久数据目录、开机自启、日志）。

S3 存储高可用方案

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 集群能扛住一个节点失联；它的 WAL 与备份流向的那个 S3 仓库却必须同样扛得住，否则"高可用"在备份这条路上悄无声息地就断了。store 是一个 MinIO 或 silo 插件（两者可互换——silo 是 Pigsty 的 MinIO 分支，功能面完全一致）。这里真正要紧的是两个互相正交的故障域：

Alertmanager

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install alertmanager 以受管容器方式运行 Alertmanager——位于 Prometheus 下游的告警去重、分组、路由与通知层——直接跑官方 docker.io/prom/alertmanager 镜像。与 Prometheus、Grafana 一样，它是顶层插件：不前置某个具体实例，也不依附于任何一个。Prometheus 与 Alertmanager 是天然一对——Prometheus 触发告警，Alertmanager 决定通知谁、怎么通知——而本插件在形状上是 Prometheus 的近乎完全同构体（单容器、Linux 上宿主网络、各自端口池里的一个 web 端口、持久数据目录、开机自启、日志、渲染配置文件 + 镜像名之后的 CLI flag、SIGHUP 热加载、无 Web 登录）。

Gitea

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install gitea 以受管容器方式运行 Gitea——轻量级自托管 Git 服务——直接跑官方上游镜像（docker.io/gitea/gitea，rootful 构建）。与 Grafana 一样，它是顶层插件：不依附于任何单个 PostgreSQL 实例，也不自动前置它们——但可以把某个 PG 实例用作自己的元数据库（见下文 --dsn）。单个容器同时提供 Web UI、Git HTTP 流量，以及 git-over-ssh（跑在镜像自带的 OpenSSH sshd 上——见下文「Git SSH」小节；无论 --ssh-port 与否这个 sshd 都在跑，该 flag 只决定它是否是活的克隆端点）。

VictoriaMetrics

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install victoriametrics 以受管容器方式运行 VictoriaMetrics——高性能、兼容 Prometheus 的时序数据库——直接跑官方 docker.io/victoriametrics/victoria-metrics 镜像。与 Prometheus 和 Grafana 一样，它是顶层插件：不前置某个具体实例（它从多个来源摄入指标），也不依附于任何一个。三者是天然搭档——Prometheus 负责采集、VictoriaMetrics 以优异的压缩率做长期存储、Grafana 负责可视化——且生命周期形状完全一致（单容器、Linux 上宿主网络、各自端口池里的一个 web 端口、持久数据目录、开机自启、日志）。

BeeGFS

Mon, 01 Jan 0001 00:00:00 +0000

BeeGFS 是一套走「易用」路线的并行文件系统：2004 年生于德国弗劳恩霍夫工业数学研究所（ITWM）——当年一个课题组要用 Lustre，嫌它部署运维太重，干脆自己写了一个，目标从一开始就定死：不求规模最大，但求部署和维护最省人力。2014 年核心成员从研究所出来成立商业公司 ThinkParQ，产品改名 BeeGFS，一路从研究所内部工具长成欧洲高校与区域超算里常见的共享存储。

VMCluster

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install vmcluster 以受管容器方式运行 VictoriaMetrics 集群版——3 个组件各跑一个容器，使用官方 docker.io/victoriametrics/{vminsert,vmselect,vmstorage}:v1.154.1-cluster 镜像。与单机版 victoriametrics addon（1 容器 1 端口）不同，它管理最多 3 个容器、3 个镜像、5 个端口，支持跨主机部署和水平扩展。

JuiceFS

Mon, 01 Jan 0001 00:00:00 +0000

JuiceFS 把真正的 POSIX 文件系统铺在对象存储之上：文件数据切块后存进 S3 桶，另由一个元数据引擎（SQLite、Redis、PostgreSQL……）保存命名空间、文件属性与块映射。你拿到的是一个可以 ls、cat、grep 的普通目录——每次写入最终都化作桶里不可变的对象。「想要文件系统、但字节应该住在 S3」就是它解决的问题：快照近乎免费（对象不可变）、容量就是桶的容量、任何知道元数据 URL 的主机都能把同一个桶再挂起来。

VictoriaLogs

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install victorialogs 以受管容器方式运行 VictoriaLogs——VictoriaMetrics 家族的高性能、低成本日志数据库——直接跑官方 docker.io/victoriametrics/victoria-logs 镜像。与 VictoriaMetrics 和 Prometheus 一样，它是顶层插件：不前置某个具体实例（它从多个来源摄入日志），也不依附于任何一个。VictoriaMetrics 存指标、VictoriaLogs 存日志、Grafana 同时可视化两者——三者生命周期形状完全一致（单容器、Linux 上宿主网络、各自端口池里的一个 web 端口、持久数据目录、重启策略）。

vlagent

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install vlagent 以受管容器方式运行 vlagent——VictoriaLogs 家族的官方日志 agent、vmagent 的日志对应物——直接跑官方 docker.io/victoriametrics/vlagent 镜像。它是顶层插件：不前置某个具体 PostgreSQL 实例，是 VictoriaLogs 插件的天然搭档——VictoriaLogs 存日志，vlagent 从文件或 HTTP 采集日志并转发给一个或多个 VictoriaLogs 实例。

VLCluster

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install vlcluster 以受管容器方式运行 VictoriaLogs 集群版——可水平扩展的日志数据库。与单机版 victorialogs addon（1 容器 1 端口）不同，它管理最多 3 个容器，但三个角色共用同一个镜像（docker.io/victoriametrics/victoria-logs:v1.53.0），角色完全由启动参数区分；每台主机占用 3 个 HTTP 端口。

ZeroFS

Mon, 01 Jan 0001 00:00:00 +0000

ZeroFS 是把一切关在桶里的 S3 文件系统：不像 JuiceFS 依赖外部元数据引擎，它自己在对象存储上跑一套 LSM 树，且每个对象都用卷数据密钥加密——该密钥由你的加密口令包裹（wrap）。快照与一致性由后台 compaction 负责——没有要备份的数据库、没有要养活的 Redis。它经本地 9P 一跳再以 FUSE 挂载，日常使用与普通文件系统无异；而桶本身就是这个卷完整的、加密的副本。

DuckDB

Mon, 01 Jan 0001 00:00:00 +0000

DuckDB 是嵌入式分析数据库——常被称作"SQLite for analytics"。 C++ 编写的列式引擎，向量化执行，可以直接查询 Parquet、CSV、JSON 和 Arrow 文件，无需服务器进程。把它当成一个单二进制的 OLAP 引擎，指向你的数据即可使用：加载 httpfs 扩展后，SELECT * FROM read_parquet('s3://bucket/data.parquet') 开箱即用。

Node_exporter

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install nodeexporter 以受管容器方式运行 node_exporter——Prometheus 官方的宿主机指标导出器，在 /metrics 上发布整台机器的 CPU、内存、磁盘、网络与文件系统指标——直接跑官方 docker.io/prom/node-exporter 镜像。与 Prometheus、VictoriaMetrics、Grafana 一样，它是顶层插件：它描述的是机器，不是某个 PostgreSQL 实例，故不依附于任何一个。它是 pgcli Prometheus 插件的天然搭档——node_exporter 负责暴露、Prometheus 负责抓取。

InfluxDB

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install influxdb 以受管容器方式运行 InfluxDB 1.13.1 OSS——单节点时序数据库，TSM 存储、InfluxQL 查询——直接跑 pgcli 自建的 ghcr.io/mars-base/pgcli/pgcli-influxdb 镜像（官方 linux/amd64 发行版二进制 + Alpine）。与 VictoriaMetrics 一样，它是顶层插件，不前置任何 PostgreSQL 实例。

Pg_exporter

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install pgexporter 以受管容器方式运行 pg_exporter——Pigsty 的 PostgreSQL 指标导出器——直接跑官方 docker.io/pgsty/pg_exporter 镜像。node_exporter 插件描述的是机器，而 pg_exporter 描述的是一个数据库：它连上某个 PostgreSQL 服务，在 /metrics 上发布约 460 个 pg_* 指标（活动、锁、复制、膨胀、WAL、按库统计……）。与 Prometheus、VictoriaMetrics、Grafana、node_exporter 一样，它是顶层插件：本身不依附任何实例——而是指向它监控的目标。

influx2tsdb

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install influx2tsdb 以受管容器方式运行 influx2tsdb-proxy 1.3.2—— 一个 InfluxDB 1.x HTTP API 适配器（Line Protocol 写入、InfluxQL 查询），数据落到启用了 TimescaleDB 扩展的 PostgreSQL。镜像由 pgcli 自建： ghcr.io/mars-base/pgcli/pgcli-influx2tsdb。与 InfluxDB 插件不同，这里没有 TSM 引擎：每个数据点都存进 TimescaleDB hypertable，代理本身无状态。

ClickHouse

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install clickhouse 以受管容器方式运行 ClickHouse 26.8 LTS——单机列式 OLAP 数据库——直接跑官方 docker.io/clickhouse/clickhouse-server 多架构镜像。与 VictoriaMetrics、InfluxDB 一样，它是顶层插件，不前置任何 PostgreSQL 实例。

Kafka

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install kafka 以托管容器方式运行 Apache Kafka 4.4.0，直接使用官方 docker.io/apache/kafka 多架构镜像。Kafka 4.x 是 KRaft-only：元数据 controller 内建在 broker 进程里（process.roles=broker,controller，combined 模式），不安装也不依赖 ZooKeeper。

RabbitMQ

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install rabbitmq 以托管容器方式运行 RabbitMQ 4.4.0，直接使用官方 docker.io/library/rabbitmq 的 -management 镜像（内含 Web UI 与 HTTP API）。和 Kafka、ClickHouse 一样，RabbitMQ 是顶层插件：pgcli 负责渲染 rabbitmq.conf、管理管理员账号、绑定挂载数据目录，并以 host 网络启动容器。

RocketMQ

Mon, 01 Jan 0001 00:00:00 +0000

pg addon install rocketmq 以托管插件方式运行 Apache RocketMQ 5.x，使用官方 docker.io/apache/rocketmq 镜像。和 Kafka、ClickHouse、RabbitMQ 一样，它是顶层插件，不代理某个 PostgreSQL 实例。

pgcli

扩展目录

内置扩展（45 个）

意见反馈

PgBouncer

常用扩展

性能与监控

数据类型与标识符

搜索与文本

安全与加密

地理空间

AI 与向量搜索

时序数据

定时任务与分布式

外部数据

兼容性说明

技术支持

微信

Etcd

付费订阅

PgDog

Garage

Patroni 高可用

Patroni 动态配置

PostgREST

SeaweedFS

Patroni REST API

查找 REST API

RustFS

HA 集群扩展安装

为什么不能用 pg extension install？

HAProxy

Silo

MinIO

Patroni 集群备份

Redis

Patroni 集群恢复

Predixy

HA Exec / psql

pgAdmin 4

Nginx

示例：HA 集群 + 自签 CA 的 MinIO

Grafana

生成证书 —— pg cert

Prometheus

S3 存储高可用方案

Alertmanager

Gitea

VictoriaMetrics

BeeGFS

VMCluster

JuiceFS

VictoriaLogs

vlagent

VLCluster

ZeroFS

DuckDB

Node_exporter

InfluxDB

Pg_exporter

influx2tsdb

ClickHouse

Kafka

RabbitMQ

RocketMQ

为什么不能用 `pg extension install`？