飞哥专栏为什么优秀的开源项目都选择了 PostgreSQL？配合FastAPI就是王炸
最近在几个AI项目中深度使用了 PostgreSQL 18，不说，这确实是我用过最"懂开发者"的数据库。从简单的CRUD到复杂的向量检索，PG 都能优雅应对，难怪这么多明星项目都选择了它。
看看大佬们都在用什么
Supabase 第一时间就跟进了 PG 18，N8N 的底层也是 PostgreSQL。让我意外的是，这么多我日常在用的开源项目都在用 PG，dify.ai，NocoBase：
- GitLab： DevOps 全家的核心数据库
- Discourse： 现代论坛系统，官方只支持 PG
- Mastodon： 去中心化社交网络的主库
- Sentry： 错误追踪平台的服务端存储
- Hasura： 直接把 PG 变 GraphQL API
- Dify： 企业级 AI 平台，默认就用 PG
- Matrix： 开源IM服务器，生产推荐 PG
还有 Odoo、Zulip、Metabase、Airbyte… 这个名单长得能写满一屏。作为技术选型的重要参考，跟着这些经过实战检验的项目走，准没错。
PG 的"瑞士军刀"进化史
我习惯把 PG 比作数据库里的"瑞士军刀"——从1986年伯克利实验室诞生开始，它就坚持一个理念：既要功能强大，又要用得顺手。
- 1986年：Postgres 项目启动，目标是打造"比 Ingres 更未来的"数据库
- 1996年：加入 SQL 支持，改名 PostgreSQL，开始走群众路线
- 2000s至今：可扩展哲学深入人心——你要 JSON？给！要向量检索？装个扩展就行！要并行查询？安排！
这种设计理念让 PG 不只是个"存数据的盒子"，而是能真正"理解数据"的智能平台。
MySQL 很好，但…
先说结论：MySQL 依然是很优秀的数据库，特别适合轻量级应用和简单业务场景。
但在AI时代，当我们面临：
- 海量半结构化数据（JSON文档）
- 实时向量检索（RAG应用）
- 复杂分析报表
- 高并发事务处理
时，PG 的底层优势就显现出来了。这不是谁好谁坏的问题，而是选择合适的工具做合适的事。
PG 18：我用下来的真实体验
最近在几个AI项目中用了 PG 18，这几个特性让我印象深刻：
- JSONB + 向量检索黄金组合：存文档元数据 + 做向量搜索，一个库搞定
- 并行查询真香：复杂报表跑起来比之前快了不少
- 扩展生态成熟：pgvector、Timescale 这些扩展用起来很稳
- 运维体验提升：监控诊断视图更丰富了，排查问题更轻松
最让我惊喜的是和 FastAPI 的配合——异步连接池 + 原生异步支持，写出来的代码既简洁又高效。
实战建议：什么场景该选 PG？
从我这些项目的经验来看，如果你在做：
- ✅ AI应用：向量检索 + 结构化数据混合查询
- ✅ 复杂业务系统：JSON文档 + 事务一致性要求高
- ✅ 实时分析：窗口函数 + 并行查询需求多
- ✅ 微服务架构：需要跨库查询和数据联邦
那么 PG 18 绝对是你的首选。它就像那个什么都会的全能型队友，让你能更专注于业务逻辑而不是数据库调优。
写在最后
技术选型没有银弹，但 PG 确实是我近年来用过最惊喜的数据库。它的强大不在于有多少炫酷功能，而在于每个功能都设计得恰到好处，用起来特别顺手。
如果你还没尝试过 PG，我强烈建议你在下一个项目中给它一个机会——说不定你也会像我一样，用了就回不去了。我的一个朋友用 PG 做底层量化，目前效果刚刚的。
强烈推荐FastAPI + PostgreSQL的王炸组合。