PostgreSQL DB
2026-08-26
这篇文章（Dr. Raphael A. Bauer 的《PostgreSQL for Everything》）的核心论点是：PostgreSQL 不是万能答案，但能覆盖你想象中多得多的场景；在中小规模下，先用 PG 统一数据层，遇到真实瓶颈再换专用系统，是更省维护成本、更快交付的架构选择。
PostgreSQL 凭借“老牌稳定 + 现代特性 + 插件生态”，在初创和中型业务里可以一个数据库顶住搜索、文档、队列、时序、向量、缓存、层级数据等多套中间件；它的真正价值不是性能碾压专用库，而是用更低的运维与认知成本，让你把时间花在业务功能上。
一、为什么选 PostgreSQL：三个底层优势
- 成熟且持续进化：1996 年至今，bug 被长期打磨；社区向后兼容地加现代特性（CTE、分区、JSONB、逻辑复制等）。
- 部署与生态极简：本地 brew/apt/docker、Testcontainers 测生产一致性、云厂商一键托管，维护成本极低。
- 可扩展性强：原生能力 + 插件（TimescaleDB、pgvector、pgai、LTREE 等）把多种数据模型收进同一个 ACID 库。
二、PG 能“单库替多中间件”的场景清单
作者用自己 CTO 生涯的实战说明，以下场景不必急着引入专用组件：
| 原本的专用系统 |
PostgreSQL 方案 |
关键机制 |
| MySQL + Lucene/Solr |
原生全文检索 |
tsvector + GIN 索引（Contentful、Instacart 实践） |
| MongoDB |
文档存储 |
jsonb + GIN，支持 JSONPath 查询 |
| Kafka / RabbitMQ / SQS |
表即队列 |
FOR UPDATE SKIP LOCKED、递归/游标消费，先 PG 后换 MQ |
| ClickHouse / InfluxDB |
时序数据 |
TimescaleDB 超表 + 连续聚合 |
| Pinecone / 专用向量库 |
向量检索 |
pgvector，pgai 做 embedding 同步与 RAG |
| Redis 缓存 |
内存级缓存 |
UNLOGGED 表 + 触发器模拟 TTL，多数用例够快 |
| 文件系统存小二进制 |
Blob 列 |
Flatbuffers 序列化入 bytea，缓存策略下比裸文件 IO 更快 |
| 树形/层级数据 |
LTREE 类型 |
比递归 CTE 更易维护 |
| 微服务中间层 |
直接出 JSON |
查询里拼 JSON 返回，省一层应用中间层 |
作者强调：这些都是“先 PG 起步”的策略，不是否认专用系统——当吞吐/并发/规模真正打满时，再切 Kafka、ClickHouse、Redis 不迟。
三、架构哲学：用“无聊”换速度
- 少零件 = 少同步 = 少漂移：避免 ES 与 PG 双写、Mongo 与 PG 对账这类管道腐烂。
- 团队认知负担下降：一套 SQL 技能覆盖关系、文档、搜索、队列、时序、向量。
- 决策顺序建议：新需求来了先问“PG 能不能做”→ 能做就用 → 压测出真实瓶颈再引入新技术，而不是反过来为“技术新鲜感”买单。
这篇文章带来很好的启发：PostgreSQL拥有多模型存储能力，原生支持文档（jsonb）、轻量缓存、全文检索、向量检索、队列表等场景。在不少业务场景下，可以优先基于PG实现相关能力，避免盲目引入新的中间件，降低系统复杂度。
但我不认同将其作为一套可直接落地的生产级通用方案，存在明显边界约束（架构收敛不能牺牲稳定性）：
- 把缓存、海量文档等旁路能力并入同一套业务主库，存在严重稳定性风险。
业务主库承载核心交易、用户等核心数据，属于不可丢失的Source of Truth。缓存、高频半结构化读写具备流量大、允许降级、可丢失的特征，二者共用数据库会造成资源互相抢占、故障域合并；缓存流量抖动、jsonb频繁更新引发的膨胀与IO压力，会直接拖慢核心业务SQL，极端场景导致全站故障。
- 如果为了替代Redis、MongoDB等而新部署一套PostgreSQL，无法降低架构成本，反而是牺牲性能、增加运维负担。
新增独立PG集群会带来额外的机器、运维、监控、高可用成本，相比直接引入轻量专用组件，总体成本更高，违背“简化架构”初衷。
适用场景：
- 新项目、初创项目、MVP阶段：快速迭代优先，减少中间件维护成本，等业务出现真实瓶颈后再拆分专用组件；
- 内部系统、后台管理平台、低频运营系统：无C端高并发压力，可用性要求适中；
- 边缘业务、工具类、小型独立服务：规模有限，无需搭建复杂中间件体系。
PostgreSQL Supabase 低代码
2026-08-09
Supabase 是一个以 PostgreSQL 为核心的开源 Backend-as-a-Service（BaaS）平台，定位类似 Firebase，但采用 PostgreSQL 作为核心数据库。它通过多个独立服务提供完整的 Backend 能力。
PostgreSQL API RESTful
2026-08-08
PostgREST 2014 年前后提出并验证了“PostgreSQL 直接作为 Backend、自动生成 REST API”这条路线。
2016 年，pREST 作者认为 Haskell 在他们的团队环境中招聘和维护成本较高，因此选择 Go 来重新实现。
二者定位高度重合，核心共同点都是把 PostgreSQL 数据库直接转换成 REST API，减少传统 Backend 中 Controller、CRUD Repository 等代码。
没有深入使用，暂时不了解两者在技术栈、扩展能力和设计理念的细致差别。
PostgreSQL MySQL
2023-11-12
PostgreSQL
2023-06-20
面向进程模型是一种数据库系统的架构模型，核心思想是将不同的数据库服务分配给不同的进程，每个进程独立运行，相互之间通过进程间通信（IPC）进行协作。
这种模型被广泛应用于数据库系统中，例如 PostgreSQL 数据库系统。
正如上文所说，进程模型使得 PostgreSQL 可以将不同的服务分配给多个进程独立运行，每个进程负责不同的任务，例如查询处理、并发控制、锁管理等。
进程模型还可以可以保证系统的稳定性和可靠性。当一个进程出现问题时，不会影响到其他进程的正常运行，从而提高了系统的可用性。
这样的特点使得 PostgreSQL 可以同时处理大量的并发请求，提高了系统的性能和响应速度；
除此之外，PostgreSQL 还可以很容易地进行水平扩展，增加更多的节点以应对更高的负载。
不过与此同时，也让 PostgreSQL 面对着管理和维护成本相对较高、需要较为复杂的进程间通信和协调机制、需要消耗更多的系统资源等缺点。
6 月初，Heikki Linnakangas 发布了将 PostgreSQL 转为线程模型的提案。
线程模型是一种数据库系统的架构模型，与面向进程模型类似，它是将不同的数据库服务分配给不同的线程，每个线程独立运行，相互之间通过线程间通信进行协作。线程模型在一些轻量级的数据库系统中得到广泛应用，例如 SQLite。
线程模型与进程模型的最大区别在于，线程模型中所有的线程共享同一个进程的地址空间，每个线程有自己的堆栈，共享代码段和数据段。这意味着线程之间可以直接访问同一份内存，因此线程间通信的成本相对较低，不过这也意味着线程间的数据共享可能会带来安全性问题。
从进程模型转换成线程模型的优缺点：
优点
- 更轻量级：线程模型相对于进程模型更加轻量级，可以更加高效地使用系统资源，尤其是在单机上运行多个实例时，线程模型可以将多个实例运行在同一个进程中，减少了系统调用和进程间通信带来的开销。
- 更高的响应速度：线程模型中线程之间的通信成本相对较低，因此在高并发场景下具有更高的响应速度。
- 更少的内存占用：线程模型中线程共享同一份地址空间，因此可以避免进程模型中同一份代码和数据被多个进程重复加载到内存的问题，节省了系统内存占用。
缺点
- 安全性问题：线程之间共享同一份内存，可能会带来安全性问题，例如数据竞争和锁竞争等。
- 可靠性问题：线程模型中一个线程崩溃可能会影响到整个进程的稳定性和可靠性。
- 多线程编程难度较大：线程之间的通信需要进行同步和互斥，编写多线程程序的难度相对较大。
PostgreSQL 开发者、EnterpriseDB 高级数据库架构师 Andres Freund 指出：
我认为原有流程模型开始产生诸多限制，这个问题在大型设备上体现得尤其明显。
跨进程上下文切换所带来的开销，原本就比在同一进程内的不同线程间切换要更高 —— 我估计这种开销还将持续提升。
面对大量连接，整个体系最终一定会因 TLB 未命中而浪费大量时间。
这是进程模型无法跨进程共享 TLB 的天然属性造成的必然结果。
目前这还仅仅只是一项提议，并且由于 PostgreSQL 被广泛用于生产环境，转换到线程模型的过程需要非常谨慎。开发团队需要在不影响现有生产环境的情况下测试新的线程模型，以确保其稳定性和可靠性。即便这个提议通过，这个转化过程肯定也是无法通过单一版本彻底完成，从网上的各方评价来看，目前大多数人都支持这项提议。
开发工具 GitLab MySQL PostgreSQL
2019-07-03
看到新闻，Gitlab 从 12.1 版本开始将不再支持 MySQL，理由是：
Gitlab 支持的另一个数据库是 PostgreSQL，意思是 PostgreSQL 不存在上面的问题。
这也可以看作是二者的部分区别吧！
值得研究研究。
