• andie

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

    万物借口 PostgreSQL
    包括你的 PS5

    再多夸点,爱听

    主楼
  • chjqpmain

    感谢分享,(虽然目前只看了首页,里面链接的跳转还没读,但起夜的精神消耗光了,只能先睡觉了)

    #1
  • vcfger

    感谢分享,白天仔细读下,

    #2
  • Thesara

    我想起一个博主叫原子能,经常看到他拿 PgSQL 疯狂尊重 MySQL

    #3
  • restkhz

    我第一个想到的也是原子能那个哥...

    #4
  • ratazzi

    https://github.com/ratazzi/quebec
    借鉴 solid queue 的任务队列,PostgreSQL 是第一优先级

    #5
  • chenzw2

    这文章是认真的吗?一个 pg 能替代了这么多个中间件?

    #6
  • thatlazyman

    开源 DB 最棒
    有人照着这个写了个 Sqlite For Everything : https://joecode.com/2026-08-19-sqlite3/

    #7
  • changdy

    你也是会取标题的. 正文里面也都只是调侃下.

    另外开源数据库你还能指望谁? mysql 还是 mariadb?

    #8
  • kapr1k0rn

    坐等冯老板出来说“我几年前就提出这个了”

    #9
  • layxy

    如果这么多中间件都使用 pgsql ,那性能不得爆炸了,任何一个导致 pgsql 性能问题大概率会影响其他的,直接血崩,这个感觉适合个人项目或早期验证项目,实际生产级的还是专业的事交给专业的工具

    #10
  • Cabana

    同喜同喜,自己所有项目只用 psql 或者 sqllite

    #11
  • foufoufm

    @Cabana 我靠,同样啊,我自己的项目也只用这两个

    #12
  • woodfizky

    本站有 PostgreSQL 节点的,还是发到程序员节点了。额。。能移可以考虑移动一下。

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

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

    反正方案被否了,老老实实回去用 ES 那套了。

    #13
  • Configuration

    @layxy 中小型项目希望减少依赖会用这个方案,大型项目还是该怎么拆仍旧怎么拆

    #14
  • liangc230323

    @Thesara 全网最尊重 Mysql 博主

    #15
  • cutiechi

    @woodfizky 不是有 gp 吗

    #16
  • woodfizky

    GP 是啥? Greenplum ?

    #17
  • YanSeven

    @一下全网最尊重 PG 的个体户——冯若航

    #18
  • Maerd

    我们的项目用 pg+fsm 替代了消息队列,效果很好,因为我们有一个任务系统,涉及很麻烦的订单流转、取消、审核、申诉、重入、冻结各类异步状态,还有一大堆的细粒度权限管控。消除了消息队列,配合事务+fsm 后,最大的收益是不需要考虑一致性问题了,心智负担爆减;
    唯一最大的问题是,由于现在分布式数据库大多是存储和计算分离,所以相比之前的消息队列成本翻了接近 10 倍(虽然和收益相比不算什么)

    #19
  • YanSeven

    @Maerd 请教下,为啥在存算分离的 pg 上使用消息队列会导致比消息队列的成本翻 10 倍呢。

    #20
  • mywaiting

    我一直觉得宣传 PG 能够后端一锅端是对 PG 的伤害.....

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

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

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

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

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

    是的,这个也用来总结 PG 一锅端就很合适:可以用、不好用、没必要

    #21
  • zengxs

    All in One = All in Boom

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

    文章案例 PG 取代 MongoDB ,我以前还真试过,PG 在这个场景性能比 MONGO 差不止一点

    #22
  • unpay

    在用。。很丝滑。。

    #23
  • yjhatfdu2

    @woodfizky 是 gauss 垃圾,华为的软件能用?你用正版 pg+那几个新的全文索引/向量索引试试

    #24
  • woodfizky

    不是我不想,甲方不给引进,不然为啥要从 PG 转高斯?
    转到高斯连 json 索引和 gin/gist 索引都不支持了。
    一句话要求能转信创都转信创,说是有问题信创团队兜底。一问为什么不支持索引/扩展,信创团队全部支支吾吾。
    华为的钱还是太好赚了。。

    #25

发表回复

登录后回复