北京
一个开发者论坛的热门帖子，用一张决策树终结了持续多年的争论。PostgreSQL还是SQLite？答案比想象中更绝对。
发帖人开门见山：几乎所有面向公众的Web应用或SaaS，都应该选PostgreSQL。SQLite只属于嵌入式、本地优先或极低流量的内部工具。这不是观点，而是基于并发、安全、可靠性三个维度的硬性边界。
先看普通Web应用的场景。博客、小型电商、企业官网——这些看似简单的需求，一旦并发用户超过5到10人，差距立刻显现。PostgreSQL支持真正的多用户并发，有完善的权限隔离，能在共享主机上稳定运行，且数据安全机制成熟。SQLite则会出现"数据库被锁定"的错误，没有用户级别的权限控制，写入时整个文件被锁定，高并发下直接崩溃。
但SQLite并非一无是处。演示项目、单用户仪表盘、基于Electron的本地桌面应用、开发测试环境——这些场景下它表现出色。零配置、单文件、跨平台复制，确实是工程杰作。问题是，很多开发者误把"开发时好用"当成"生产环境够用"。
SaaS场景将差距进一步放大。多租户架构需要严格的数据隔离，自动扩缩容要求数据库能水平扩展，合规审计需要细粒度日志，分析业务需要复杂查询优化。更关键的是零停机迁移——SaaS产品不能告诉用户"我们要维护两小时"。PostgreSQL有成熟的工具链应对这些需求，SQLite则完全没有对应能力。
帖子中唯一认可的"SaaS+SQLite"组合，是边缘计算场景。通过LiteFS或Turso等工具，将只读的SQLite副本部署到全球边缘节点，实现超低延迟读取。但注意前提：主写入节点依然是PostgreSQL。SQLite在这里只是缓存层，不是数据源。
决策树的设计很直白。第一个问题：并发用户是否超过5人？是，直接PostgreSQL。否，继续问：能否容忍偶尔的数据库锁定错误？不能，还是PostgreSQL。能，再问：是否是本地工具、移动应用或命令行程序？是，SQLite合适。否，依然建议PostgreSQL——为未来留余地。
这个流程揭示了一个常被忽视的陷阱：技术选型不是匹配当前需求，而是匹配需求演进的上限。很多项目初期确实只有单用户，但"可能以后会扩展"不是选SQLite的理由，反而是不选它的理由。迁移数据库的代价，远高于初期多配置一个PostgreSQL实例。
帖子最后总结了一条简单规则：生产环境默认PostgreSQL，只有出现明确的反向理由时才考虑SQLite——嵌入式设备、本地优先桌面应用、测试环境。SQLite在其领域内无可替代，但多租户SaaS不在那个领域内。
这个判断与数据库领域的长期实践一致。SQLite的创造者D. Richard Hipp在设计之初就明确了定位：嵌入式数据库，而非服务器数据库。它的测试套件超过一亿行，可靠性极高，但设计目标从未包含高并发网络服务。理解这一点，比比较功能列表更重要。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
