最近刷到一篇围绕 Hacker News 上的讨论：《I run multiple 20/month tech stack》
全文英文讨论，看着很费劲，核心主题就是：小团队、独立开发者、一人公司是否真的需要一开始就上复杂云原生架构。
其实只要有5-10年经验以上的开发者，大多数人的第一反应肯定是“不需要”，下面小北一起带大家深入聊聊这个话题。
小团队如何避免过度工程
很多开发者在做 SaaS、独立产品、一人公司时，第一反应往往是：
“我要不要上 Kubernetes？”
“数据库是不是必须用 Postgres？”
“要不要多可用区、高可用、读写分离？”
“是不是一开始就要 serverless、微服务、Redis、消息队列、监控全家桶？”
这篇文章和 HN 讨论给出的答案很直接：
大多数早期产品，真正需要的不是复杂架构，而是能快速上线、低成本运维、足够稳定、方便迭代的简单系统。
一、文章核心观点
这篇文章最重要的观点不是“SQLite 一定比 Postgres 好”，也不是“VPS 一定比云服务好”。
它真正想表达的是：“适合您的才是最好的”
在产品早期，技术栈应该服务于业务验证，而不是提前模拟大厂架构。
如果你还没有真实用户、没有稳定收入、没有明确的性能瓶颈，却先把系统做成 Kubernetes + 微服务 + 多数据库 + 多区域高可用，很多时候不是专业，而是过度工程。
更合理的做法是：
-
先用一台便宜 VPS 跑起来；
-
用单体应用降低复杂度；
-
用 SQLite 或本机数据库减少网络和运维成本；
-
用 Caddy/Nginx 做反向代理和 HTTPS；
-
用简单可靠的备份方案保障数据；
-
等业务真的增长后，再根据瓶颈升级架构。
二、为什么一台 VPS 可能已经够用了？
很多开发者低估了单机能力。
对于一个早期 SaaS 来说，如果日活不高、请求量不大、业务逻辑不复杂，一台 5 到 20 美元/月的 VPS 其实可以撑很久。讨论中也有人提到，很多“企业级项目”虽然花费几千美元/月跑在复杂云架构上，但实际请求量可能远远达不到单机瓶颈。
单机架构的好处很明显：
| 维度 | 单机 VPS 架构 | | --- | --- | | 成本 | 极低，通常几美元到几十美元/月 | | 部署 | 简单，SSH + systemd + Docker Compose 就能搞定 | | 调试 | 问题集中在一台机器上，排查成本低 | | 性能 | 本地调用、本地磁盘、本地数据库，延迟很低 | | 适合阶段 | MVP、早期 SaaS、独立开发者、小团队产品 |
单机不是不能扩展，而是它把复杂度延后了。
这点对一人公司尤其重要：
你的最大瓶颈通常不是服务器性能，而是产品、用户、销售、内容、获客和持续迭代。
三、SQLite 为什么被重点讨论？
文章和评论区大量讨论了 SQLite。
很多人对 SQLite 的印象是：
“它不是玩具数据库吗？”
“生产环境能用吗？”
“并发不行吧？”
“以后是不是还得迁移到 Postgres？”
但讨论里有一个关键观点：
SQLite 的优势不是功能最多，而是它足够简单、足够快、部署成本极低。
SQLite 是嵌入式数据库，应用可以直接通过本地文件访问数据库，不需要像远程 Postgres 那样经过网络连接、数据库服务进程、连接池等链路。
因此在很多小型 Web 应用里，它的延迟和吞吐表现非常好。讨论中也有人指出，SQLite 和 Postgres 即使都在同一台机器上，SQLite 仍然有进程内调用的优势；
但也有人反驳说，简单微基准不能代表真实业务场景。
所以更准确的结论是：
SQLite 很适合读多写少、单机部署、业务模型简单、追求低运维成本的产品；但它不是所有场景的银弹。
四、SQLite 生产使用时必须注意什么？
如果你想在真实项目里使用 SQLite，不建议直接用默认配置。
讨论中有人提到，SQLite 的默认配置并不适合大多数 Web 应用，通常需要设置一些 PRAGMA 参数，例如：
PRAGMA journal_mode = WAL;
PRAGMA foreign_keys = ON;
PRAGMA busy_timeout = 1000;
PRAGMA synchronous = NORMAL;
PRAGMA trusted_schema = OFF;
这些配置背后的含义是：
|
配置
|
作用
|
| --- | --- |
| journal_mode = WAL |
开启 WAL 模式，提高读写并发能力
|
| foreign_keys = ON |
启用外键约束，避免数据关系失效
|
| busy_timeout = 1000 |
写锁冲突时等待一段时间，而不是立即失败
|
| synchronous = NORMAL |
在性能和安全性之间取得平衡
|
| trusted_schema = OFF |
提升安全性，尤其是 SQLite 作为文件格式使用时
|
此外，SQLite 更适合采用：
-
读写连接分离；
-
应用层管理写队列；
-
避免大量长事务；
-
避免多个写入者同时竞争；
-
对备份和恢复流程做真实演练。
也就是说，SQLite 可以很强，但你不能把它当成“什么都不用管”的数据库。
五、Postgres 什么时候更适合？
文章并不是否定 Postgres。
评论区也有不少人指出，Postgres 的价值在于：
-
更成熟的并发写入能力；
-
更强的查询优化器；
-
更丰富的数据类型；
-
更好的复杂报表和分析能力；
-
更成熟的复制、高可用、权限和运维生态；
-
后续扩展到多服务、多实例时更自然。
所以，如果你的系统有下面这些特征，Postgres 可能更合适：
| 场景 | 更推荐 | | --- | --- | | 多服务共享一个数据库 | Postgres | | 写入并发很高 | Postgres | | 大量复杂 SQL、报表、分析 | Postgres | | 需要成熟权限体系 | Postgres | | 需要长期企业级演进 | Postgres | | 只是早期 MVP、小型 SaaS | SQLite 或本机 Postgres 都可以 |
一个比较务实的选择是：
早期可以 SQLite，业务复杂后迁移；也可以一开始就在同一台 VPS 上跑 Postgres。
关键不是选哪个数据库显得更专业，而是选哪个更符合你当前的约束。
六、备份和高可用：不要混为一谈
讨论中关于 HA，也就是高可用，争议很大。
有人认为： “用 Litestream 把 SQLite 持续备份到对象存储，就可以快速恢复。”
也有人反驳： “备份不是高可用，备份更准确地说是灾难恢复。”
这个区分很重要。
| 概念 | 解决的问题 | | --- | --- | | 备份 Backup | 数据丢了能不能恢复 | | 灾难恢复 DR | 机器挂了后能不能在另一台机器恢复服务 | | 高可用 HA | 当前机器挂了，系统能不能几乎无感切换 | | 多活 Multi-region | 多地区同时提供服务，并处理一致性问题 |
对早期产品来说，最现实的优先级通常是：
-
先有定时备份；
-
再验证恢复流程；
-
再做异地备份；
-
有收入和用户规模后，再考虑热备、高可用、多区域。
不要一开始就为了 99.999% 可用性，把系统复杂度拉满。
七、文章真正值得学习的是“约束优先”
这篇讨论里有一个很值得学习的架构方法：
不要先问“什么技术最先进”，而要先问“我的约束是什么”。
比如作者/评论者给出的约束是：
-
小团队；
-
单机部署；
-
希望快速开发；
-
希望低成本；
-
希望少运维；
-
业务收入优先；
-
不想在基础设施上花太多时间。
在这种约束下，合理选择自然会变成：
-
单体应用；
-
SQLite 或本机数据库；
-
VPS；
-
Caddy；
-
简单部署脚本；
-
Litestream/Restic/rsync 做备份；
-
必要时再升级。
但如果你的约束不同，技术选择也会不同。
比如：
| 约束 | 技术选择可能变化 | | --- | --- | | 要快速上线后台管理系统 | Rails / Django / Laravel | | 团队熟悉 Java | Spring Boot + MySQL/Postgres | | 面向企业客户 | 权限、审计、备份、稳定性优先 | | 海量用户分布全球 | CDN、多区域、缓存、队列、分布式架构 | | 一人公司验证产品 | 单体 + VPS + 简单数据库 |
所以这篇文章的学习价值在于：架构不是套模板，而是根据约束做取舍。
八、给独立开发者/一人公司的落地技术栈建议
如果你现在要做一个小 SaaS、内容工具、自动化工具、代账类工具、公众号工具、AI 编程辅助平台，我会建议从下面这套开始。
方案 A：最小成本 MVP 技术栈
-
前端：普通 HTML / Vue / React / Thymeleaf
-
后端：Spring Boot / Django / FastAPI / Node.js
-
数据库：SQLite 或 MySQL/Postgres 单机版
-
部署：一台 VPS
-
反向代理：Caddy 或 Nginx
-
进程管理：systemd 或 Docker Compose
-
备份：定时备份 + 对象存储
-
监控：Uptime Kuma + 日志文件
这套架构适合：
-
个人项目；
-
MVP；
-
内部工具；
-
低并发 SaaS；
-
早期收费产品；
方案 B：稍微稳一点的早期商业化架构
-
前端：Vue / React
-
后端：Spring Boot / FastAPI
-
数据库：Postgres 或 MySQL
-
缓存：先不用，必要时 Redis
-
部署：1 台应用服务器 + 1 台备份服务器
-
对象存储：腾讯云 COS / 阿里云 OSS
-
反向代理：Nginx / Caddy
-
CI/CD：GitHub Actions / Jenkins / 云效
-
监控：Uptime Kuma + Prometheus 可选
-
备份：数据库每日全量 + 增量/日志备份
这套更适合已经有真实客户、数据不能丢、需要长期维护的产品。
九、最终总结
这篇文章可以浓缩成一句话：
早期产品最重要的不是“架构看起来先进”，而是“系统足够简单、成本足够低、能稳定服务用户，并让你把主要精力放在产品和收入上”。
技术上，它给了我们几个重要提醒：
-
单机能力经常被低估：很多小 SaaS 一台 VPS 可以撑很久。
-
SQLite 不是玩具：在合适场景下，它非常快、非常简单、非常适合小团队。
-
Postgres 仍然很强：复杂业务、多写入、多服务、长期演进时，它更稳妥。
-
备份比高可用更早需要：先保证数据能恢复，再追求无感切换。
-
不要被“大厂最佳实践”绑架：大厂的问题，不一定是你的问题。
-
一人公司要优先控制复杂度：复杂系统会吞掉你的开发、运维和迭代时间。
-
架构选择要从约束出发：预算、团队、用户量、业务阶段，决定技术栈。
对独立开发者来说，最值得记住的是：
先用简单技术赚到第一笔钱，再用真实瓶颈驱动架构升级。
你觉得呢？
