PostgreSQL 就够了
“Postgres 包打天下”的支持者认为，这个数据库功能丰富且可扩展——涵盖队列、Pub/Sub、向量检索、分析等——因此很多团队可以简化技术栈，推迟引入 Redis、Kafka 或 Elasticsearch 之类的专用服务。批评者则反驳说，把过多逻辑和过多工作负载塞进 Postgres 会损害开发体验，让调试和迁移变得痛苦，并最终碰到扩展性或高可用性的边界，届时就必须使用专用工具或其他数据库。综合来看，大家普遍同意 Postgres 是 OLTP 以及中小型系统的优秀默认选择，但架构应当随着规模、工作负载特征和团队经验而演进，而不是追求一个“一刀切”的方案。
Postgres 在技术栈中的角色
- 许多人将 Postgres 视为一个极佳的默认选择：功能强大、可扩展，对大多数 CRUD 应用来说“足够好”，并且随着规模增长也能支撑很长时间。
- 也有人认为“一个方案适用于所有场景”并不现实：关系型数据库并不适合每一种工作负载（重 OLAP、流式处理、海量指标等）。
- 还有人强调，适合 1 人创业公司的方案，并不一定适合大公司；随着时间推移更换工具是完全正常的。
队列、Pub/Sub 和后台任务
- 把 Postgres 当作消息队列的做法被广泛使用并且受到欢迎（例如基于表构建的队列、
LISTEN/NOTIFY、WAL 消费者）。 - 强调的优点包括：可以在数据库更新的同时进行事务性入队；相比再引入 SQS/Rabbit/Kafka，基础设施更简单；还可以在数据库事务内获得“exactly-once”语义。
- 批评意见：在数据库之外实现 exactly-once 一般来说是不可能的；SQS 和其他托管队列带来扩展性和可靠性，但也增加了 IaC、访问控制、监控和认知负担。
把逻辑推入数据库
- 支持方：存储过程/触发器中的业务逻辑可能比应用代码快得多，更接近数据，并且能简化失败处理。
- 反对方：开发体验和工具链较差（调试、测试、代码审查、版本管理）；触发器会让应用代码看不到行为，难以推理；升级也会变得更脆弱。
- 不少人建议折中：把约束、校验和简单的表内行为交给数据库；把流程编排留在应用层。
SQLite vs Postgres
- 有人主张 MVP 先用 SQLite：单文件、内嵌式、设置极其简单，对很多小型应用速度也很快，适合本地/离线使用和测试。
- 也有人回应说，Postgres 的配置同样容易，而且能避免之后痛苦的数据库迁移，尤其是在已经有真实数据和并发之后。
- 关于 “N+1 查询问题” 的争论：一方认为由于进程内调用，SQLite 在很大程度上避免了这类痛点；另一方则认为 N+1 是建模/查询问题，与数据库引擎无关。
扩展性、多租户和高可用
- 在现代硬件上，Postgres 可以处理非常高的吞吐量；很多应用永远不会超出单台服务器的能力。
- 但高可用集群和水平扩展仍然被认为并不简单；人们提到分片、按租户分库，以及 Postgres 的衍生方案/扩展（例如分布式或云托管产品）。
- 多租户架构（每个客户一个数据库，或按客户分片）是常见模式；大型的单一多租户 schema 可能会变得很痛苦。
JSON、向量与专用工作负载
- Postgres 的 JSON/JSONB 受到赞赏，但也有人提醒其性能和反规范化的坑；建议是谨慎使用 JSON，不要把它当作逃避 schema 设计的借口。
- 对于指标和时间序列，建议使用 TimescaleDB 和类似扩展；对于非常大规模或实时 OLAP/指标，更偏向专用系统（ClickHouse、StarRocks、VictoriaMetrics 等）。
- 向量检索：Postgres 的扩展（例如 pgvector 及相关工具）已经存在，适合较小工作负载；在非常大规模下，专用向量数据库可能更合适。
运维复杂度与技术选型
- 一个很强的主题是：每增加一个依赖，都会带来风险（复杂度、安全性、维护成本）。延展你已经在运行的 Postgres，往往比新增服务更便宜。
- 反方观点：把 Postgres 过度负载会让它成为单一瓶颈，并可能导致“拧巴”的架构（在触发器里发 HTTP、重度使用 listen/notify 等）。
- 许多人主张“选择无聊的技术”，避免简历驱动的炫酷工具，但也要避免把 Postgres 变成唯一的锤子。