我就喜欢听人夸 PostgreSQL

9 月 14 日
 andie
好文分享 https://www.raphaelbauer.com/posts/postgresql-everything

万物借口 PostgreSQL
包括你的 PS5

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

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

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

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

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1241732

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX