我就喜欢听人夸 PostgreSQL

andie 2026-09-14 01:18 1

好文分享 https://www.raphaelbauer.com/posts/postgresql-everything

万物借口 PostgreSQL
包括你的 PS5

再多夸点,爱听
最新回复 (25)
  • chjqpmain 09-14 01:29
    1
    感谢分享,(虽然目前只看了首页,里面链接的跳转还没读,但起夜的精神消耗光了,只能先睡觉了)
  • vcfger 09-14 02:20
    2
    感谢分享,白天仔细读下,
  • Thesara 09-14 02:25
    3
    我想起一个博主叫原子能,经常看到他拿 PgSQL 疯狂尊重 MySQL
  • restkhz 09-14 07:08
    4
    我第一个想到的也是原子能那个哥...
  • ratazzi 09-14 08:16
    5
    https://github.com/ratazzi/quebec
    借鉴 solid queue 的任务队列,PostgreSQL 是第一优先级
  • chenzw2 09-14 09:01
    6
    这文章是认真的吗?一个 pg 能替代了这么多个中间件?
  • thatlazyman 09-14 09:05
    7
    开源 DB 最棒
    有人照着这个写了个 Sqlite For Everything : https://joecode.com/2026-08-19-sqlite3/
  • changdy 09-14 09:15
    8
    你也是会取标题的. 正文里面也都只是调侃下.

    另外开源数据库你还能指望谁? mysql 还是 mariadb?
  • kapr1k0rn 09-14 09:15
    9
    坐等冯老板出来说“我几年前就提出这个了”
  • layxy 09-14 09:22
    10
    如果这么多中间件都使用 pgsql ,那性能不得爆炸了,任何一个导致 pgsql 性能问题大概率会影响其他的,直接血崩,这个感觉适合个人项目或早期验证项目,实际生产级的还是专业的事交给专业的工具
  • Cabana 09-14 09:24
    11
    同喜同喜,自己所有项目只用 psql 或者 sqllite
  • foufoufm 09-14 09:28
    12
    @Cabana 我靠,同样啊,我自己的项目也只用这两个
  • woodfizky 09-14 09:34
    13
    本站有 PostgreSQL 节点的,还是发到程序员节点了。额。。能移可以考虑移动一下。

    PG 代替所有,看起来很美好。
    但是你但凡有哪个环节比较耗性能+数据量大,用 PG 自带的插件之类的解决,感觉都要打个问号。

    实际我们试了一下,用 PG 代替 Elastic ,大量数据,一定程度的并发写入 PG(每行几十兆大的数据),会出现数据库连接超时、写入超时、写入速度因为高并发变慢的问题。
    也不知道是不是负责这块的同事不太会做压力测试还是怎么样,还是说我们实际上数据库是 GaussDB(A 模式)兼容 PG 但是是旧版本 PG 魔改导致性能有差异或者核心版本落后的问题或者缺少扩展插件等的原因。
    但是就算是 PG 高版本,高并发大数据写入,用 PG 我也没一个乐观的预估。

    反正方案被否了,老老实实回去用 ES 那套了。
  • Configuration 09-14 09:34
    14
    @layxy 中小型项目希望减少依赖会用这个方案,大型项目还是该怎么拆仍旧怎么拆
  • liangc230323 09-14 09:35
    15
    @Thesara 全网最尊重 Mysql 博主
  • cutiechi 09-14 09:57
    16
    @woodfizky 不是有 gp 吗
  • woodfizky 09-14 10:15
    17
    @cutiechi #16 GP 是啥? Greenplum ?
  • YanSeven 09-14 10:18
    18
    @一下全网最尊重 PG 的个体户——冯若航
  • Maerd 09-14 11:20
    19
    我们的项目用 pg+fsm 替代了消息队列,效果很好,因为我们有一个任务系统,涉及很麻烦的订单流转、取消、审核、申诉、重入、冻结各类异步状态,还有一大堆的细粒度权限管控。消除了消息队列,配合事务+fsm 后,最大的收益是不需要考虑一致性问题了,心智负担爆减;
    唯一最大的问题是,由于现在分布式数据库大多是存储和计算分离,所以相比之前的消息队列成本翻了接近 10 倍(虽然和收益相比不算什么)
  • YanSeven 09-14 11:26
    20
    @Maerd 请教下,为啥在存算分离的 pg 上使用消息队列会导致比消息队列的成本翻 10 倍呢。
  • mywaiting 09-14 14:35
    21
    我一直觉得宣传 PG 能够后端一锅端是对 PG 的伤害.....

    PG 作为数据库之一,其最大价值是事务执行,各种牛逼的 PG 插件始终都是基于这个特性上去**适配**各种数据场景/需要

    宣扬其能**代替**系列/相关后端的实现,对中小应用有价值

    稍微上点强度/流量,还是该拆拆该分分,该代替的代替

    用之前看过 V2 网友发的一段例子做总结吧:

    Q 编程中为了部署架构简单而选择用软件 A 做功能 B 的事,比如 Redis 作为缓存也能用作队列使用,那为什么不这样做呢?
    A 可以用、不好用、没必要

    是的,这个也用来总结 PG 一锅端就很合适:可以用、不好用、没必要
  • zengxs 09-14 15:31
    22
    All in One = All in Boom

    专业的场景还得专业的工具

    文章案例 PG 取代 MongoDB ,我以前还真试过,PG 在这个场景性能比 MONGO 差不止一点
  • unpay 09-14 15:32
    23
    在用。。很丝滑。。
  • yjhatfdu2 09-14 15:56
    24
    @woodfizky 是 gauss 垃圾,华为的软件能用?你用正版 pg+那几个新的全文索引/向量索引试试
  • woodfizky 09-14 17:10
    25
    @yjhatfdu2 #24 不是我不想,甲方不给引进,不然为啥要从 PG 转高斯?
    转到高斯连 json 索引和 gin/gist 索引都不支持了。
    一句话要求能转信创都转信创,说是有问题信创团队兜底。一问为什么不支持索引/扩展,信创团队全部支支吾吾。
    华为的钱还是太好赚了。。
* 帖子来源V2EX
返回