一个开发者论坛的热门帖子,用一张决策树终结了持续多年的争论。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.