越来越多的 AI 产品在技术栈里选了 PostgreSQL——不是因为它重新包装成"AI 数据库"，而是因为它本来就是团队最熟悉、最可靠的那层基础设施。Supabase 的普及加速了这一趋势：每次创建 Supabase 项目，底层就是一个 PostgreSQL 实例。主流 AI 框架对 PostgreSQL 和 pgvector 的直接支持，让向量检索和应用数据可以留在同一个数据库里，架构更简单，运维也更可控。
但故事并不止于"选型方便"。当 AI 工作负载从原型走向生产，PostgreSQL 会从"后台基础设施"变成"主动运维责任"，这个转变比大多数团队预期的来得更快。
pgvector：把向量检索拉回关系型数据库
PostgreSQL 从 1986 年的 POSTGRES 项目起步，几十年的持续开发让它以事务可靠性、可扩展性、复制和运维稳定性著称。可扩展性这一点对 AI 应用尤其关键——pgvector 扩展让 embedding 存储和相似度搜索直接跑在 PostgreSQL 里，和应用数据共存。
这意味着很多团队不再需要单独引入一个向量数据库。embedding 和业务数据在同一套基础设施里，团队已有的运维经验可以直接复用，架构也少了一层依赖。
Supabase 进一步降低了门槛。开发者用 Supabase 做认证、API、后端基础设施时，PostgreSQL 已经在底层运行了。AI 创业公司大量采用 Supabase，PostgreSQL 自然就成了 AI 开发生态的一部分。围绕它的生态也在加固这个方向：主流 AI 框架直接支持 PostgreSQL 集成，云厂商提供成熟的托管服务，ORM 优先支持 PostgreSQL。
工作负载增长后的四个运维症状
AI 应用起步时工作负载通常不大：查询延迟可控，embedding 数量有限，基础设施利用率低。但产品增长后，情况会显著变化：
- 并发推理活动导致连接数飙升——AI 应用每个请求经常产生多次并发数据库交互，连接和内存压力快速上升。
- 向量索引增长超出预期——开发阶段有效的索引策略，在更大数据集和更高并发下表现不同。
- 负载下延迟变得不稳定——检索管道、异步推理调用、混合搜索模式对数据库施加的压力和传统应用流量不同。
- 写密集时复制延迟增加——副本上的复制滞后在重写流量下更明显。
这些症状通常逐渐出现，但 AI 工作负载加速了它们的暴露速度。
连接池与监控：从原型到生产的两道坎
连接管理是第一道坎。AI 应用频繁产生并发数据库交互，PostgreSQL 的连接数和内存使用压力增大。很多团队在原型阶段从未考虑过 PgBouncer 或 Supavisor，但并发增长后不得不评估连接池策略。
监控是第二道坎。传统仪表盘关注事务查询延迟，但向量索引行为、embedding 搜索延迟、检索特定瓶颈往往不能被及时发现。PostgreSQL 仍然能支撑工作负载，但数据库开始需要比原型阶段更高的运维关注度。
实战：在 PostgreSQL 里用 pgvector 做向量检索
下面是一个可以直接跑的完整示例，展示如何启用 pgvector、创建表、插入 embedding、建索引并执行相似度搜索。
-- 1. 启用 pgvector 扩展（需要超级用户权限，Supabase 项目默认已启用）
CREATE EXTENSION IF NOT EXISTS vector;
-- 2. 创建存储文档和 embedding 的表
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
embedding VECTOR(1536) -- OpenAI text-embedding-ada-002 输出维度
);
-- 3. 插入一条文档及其 embedding
-- 实际 embedding 由模型生成，这里用占位符示意
INSERT INTO documents (content, embedding)
VALUES (
'PostgreSQL is becoming the default database for AI applications.',
'[0.0023, -0.0117, 0.0305, ...]'::vector -- 替换为真实 embedding 数组
);
-- 4. 小数据集可以直接用精确搜索（无需索引）
SELECT id, content,
1 - (embedding <=> '[0.0021, -0.0120, 0.0298, ...]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.0021, -0.0120, 0.0298, ...]'::vector
LIMIT 10;
-- 5. 数据量增长后，建 HNSW 索引加速近似搜索
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- 6. 查询时设置 ef 参数控制搜索精度与速度的权衡
SET hnsw.ef_search = 100;
SELECT id, content,
1 - (embedding <=> '[0.0021, -0.0120, 0.0298, ...]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.0021, -0.0120, 0.0298, ...]'::vector
LIMIT 10;
几点实操提醒：
VECTOR(1536)的维度要和你使用的 embedding 模型匹配，换模型就要换维度。- HNSW 索引的
m和ef_construction参数影响索引质量和构建时间，生产环境建议先在测试数据集上调参。 hnsw.ef_search越大搜索越精确但越慢，根据业务对召回率和延迟的要求调整。- embedding 插入建议用应用代码批量写入，避免逐条 INSERT 的开销。
用 PgBouncer 缓解连接压力
AI 应用并发推理时连接数会飙升，下面是一个最小可用的 PgBouncer 配置，适合从原型过渡到小规模生产：
;; /etc/pgbouncer/pgbouncer.ini
[databases]
myapp = host=127.0.0.1 port=5432 dbname=myapp
[pgbouncer]
pool_mode = transaction ; 事务结束即释放连接，适合短查询场景
max_client_conn = 1000 ; 允许的最大客户端连接数
default_pool_size = 20 ; 到 PostgreSQL 的后端连接池大小
reserve_pool_size = 5 ; 突发时额外可用的后端连接
reserve_pool_timeout = 3 ; 等待额外连接的超时（秒）
server_idle_timeout = 300 ; 后端连接空闲超时回收（秒）
;; 认证方式——生产环境建议用 auth_file，这里用简单示例
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
对应的 userlist.txt：
"myapp_user" "md5hash_of_password"
启动 PgBouncer 后，应用连接端口改为 PgBouncer 监听端口（默认 6432），PostgreSQL 本身的 max_connections 可以降到池大小附近，内存压力显著减轻。
生产环境建议用 Supavisor（Supabase 官方连接池）或 PgBouncer 的 transaction 模式，不要用 session 模式——AI 请求的短事务特性更适合事务级池化。
运维成熟度比数据库本身更关键
一个反复出现的模式：应用成功了，AI 功能被广泛采用，产品迭代速度很快，但组织内部很少有人对 PostgreSQL 在持续生产压力下的行为有深入理解。PostgreSQL 本身足够健壮和宽容，这让问题长期处于可控状态。直到某次大客户上线、并发激增、检索模式变重，之前从未重新审视的运维假设才被暴露出来。
这类运维债务通常悄悄累积，表现为：
- 同样的性能问题在规模增长后反复出现
- 流量高峰时故障转移行为不确定
- 工程师越来越多地花时间排查查询行为
- 基础设施成本增长速度超过工作负载增长
- 对升级或架构变更越来越犹豫
问题很少是 PostgreSQL 本身——更多是运维成熟度比工作负载演进得更慢。AI 应用加速了这个压力，因为并发、向量搜索和检索密集流量引入了许多团队此前没有大规模运维过的工作负载特征。
PostgreSQL 在某个节点会从"后台基础设施"变成"主动运维责任"。继续成功运维它的团队，通常是那些在压力迫使对话之前，就主动重新审视架构、工作负载行为和运维归属的团队。PostgreSQL 本身继续扩展得很好——差异在于团队有多刻意地让系统随产品一起演进。