PostgreSQL vs SQLite：不是对手，是两种物种

把这两个放一起对比其实有点"错位"：SQLite 是嵌入在你应用进程里的库，PostgreSQL 是独立运行的服务器。它们不是竞品，而是为完全不同的场景设计的两种物种。理解这一点，选型就完成了一半。

部署形态：装不装、管不管

SQLite：import sqlite3 完事。无需安装、无服务进程、无配置文件，数据库就是一个文件。备份 = 复制文件；迁移 = 拷贝文件；版本管理测试库 = git add 文件。

PostgreSQL：apt install postgresql，系统服务常驻，建用户、建库、配权限，备份要 pg_dump 或 base backup 做时间点恢复，调优要动 postgresql.conf。

SQLite 的零运维是真的零；PostgreSQL 的运维投入换来的是下文的所有能力。

数据类型：严格 vs 随和

• PostgreSQL：类型系统严格且丰富——数组、JSONB、范围类型、网络地址、自定义类型，写入即校验；
• SQLite：类型亲和（Type Affinity）机制很宽松，声明 INTEGER 的列也能塞字符串。灵活但也意味着脏数据没人拦，约束全靠应用自觉。

并发模型：本质分水岭

这是两者最实质的差别：

SQLite：文件级锁，单写者。写操作锁整个数据库文件。WAL 模式允许"边写边读"，但任何时刻只有一个写者。桌面应用、移动 App 本地缓存毫无压力；高并发服务端场景就是死穴（参见本系列《Turso 如何解决单写者瓶颈》）。

**PostgreSQL：MVCC + 行级锁。**操作只在真正冲突时才互相等待——改 A 产品的会话和改 B 产品的会话并行不悖，数百连接同时写不同的行毫无问题。

-- 会话1：锁 product ABC 这一行
UPDATE inventory SET quantity = quantity - 5 WHERE product_id = 'ABC';
-- 会话2：改 XYZ，立即执行，互不阻塞
UPDATE inventory SET quantity = quantity - 3 WHERE product_id = 'XYZ';

性能特征：各有各的快

• SQLite 的快：进程内调用，零网络开销。SELECT * FROM users WHERE id = 42 这种简单点查比任何 C/S 数据库都快；
• PostgreSQL 的快：复杂查询（多表 Join、聚合、窗口函数）有多核并行执行、成熟优化器和各种索引类型加持，数据越大越复杂优势越明显。SQLite 再快也是单线程执行复杂查询。

文件与备份哲学

# SQLite：整个数据库是一个文件
cp app.db backup.db          # 备份
scp app.db server:/data/     # 迁移
git add test.db              # 给测试库做版本管理

# PostgreSQL：数据目录里一堆文件，别直接动
pg_dump mydb > backup.sql    # 逻辑备份
# 或用 base backup + WAL 做 PITR 时间点恢复

SQLite 的可携带性无敌；PostgreSQL 的备份体系为"永不丢数据"设计。

运维复杂度

SQLite 的"运维"就是 PRAGMA journal_mode=WAL; 然后忘了它。PostgreSQL 要盯连接数、分析慢查询、定期 VACUUM、按负载调参数——这些不是负担，是你对生产系统的控制权。

决策速查

一个常见演进路径：用 SQLite 起步验证产品，流量上来后迁移到 PostgreSQL——两者都是标准 SQL，迁移成本相对可控。

观测云对照

用 PostgreSQL 做生产库时，观测云 DataKit 的 PostgreSQL 集成采集连接、慢查询、锁等待、复制延迟等指标，监控器对异常自动告警——把上一节说的"运维动作"全部可观测化。SQLite 场景虽无需数据库监控，但嵌入它的应用本身仍可通过 APM 观测 SQL 调用耗时。 1 2 3

常见问题（FAQ）

Q：SQLite 能扛多少并发？
读并发很好（WAL 模式下读者互不阻塞）；写并发天花板是 1。经验值：每天几万次写入的网站完全够用，每秒数百并发写就该换了。

Q：SQLite 数据安全吗？会不会容易损坏？
SQLite 的事务是完整 ACID 的，崩溃恢复久经考验（它是全球测试最充分的软件之一）。损坏多因不当使用（网络文件系统上跑、强制断电且未开同步）。

Q：有没有中间态产品？
有：轻量 PostgreSQL 发行版、嵌入式 PostgreSQL 项目，以及给 SQLite 加并发能力的 Turso/libSQL（见本系列第 7 篇）。生态正在填补两者之间空白。

Q：为什么不全用 PostgreSQL？
因为杀鸡不该用牛刀。一个手机 App 的内嵌数据库跑服务器进程是荒谬的。工具匹配场景，才是工程美学。

参考资料

• 观测云 PostgreSQL 集成
• 观测云监控器与告警
• 观测云应用性能监控 APM