SQLite 和 MySQL、PostgreSQL 有什么区别？怎么选？
SQLite、MySQL、PostgreSQL 都是关系型数据库，但它们解决的问题不一样。SQLite 是嵌入式数据库，数据通常就是一个文件；MySQL 和 PostgreSQL 是客户端/服务器架构，有独立进程负责连接、权限、缓存、并发和后台维护。选型时不要只问“谁更快”，更应该问“谁更适合这个运行环境”。
架构差异决定使用边界
SQLite 的优势是零配置、低延迟、部署简单。应用只要能读写文件，就能打开数据库，非常适合移动端、桌面软件、浏览器扩展、本地缓存、测试环境和小型内部工具。MySQL、PostgreSQL 的优势是多用户、高并发、权限体系、复制、监控和运维生态，适合 Web 后端和多人共享业务系统。
sqlite3 app.db '.schema' sqlite3 app.db 'SELECT count(*) FROM user;'
这两条命令就能直接查看 SQLite 文件里的结构和数据。换成 MySQL 或 PostgreSQL，你通常要先连接服务、认证用户，再访问指定库。
并发模型差异很关键
SQLite 支持多读单写，WAL 模式能让读写更少互相阻塞，但同一时间仍然只有一个写者。MySQL 和 PostgreSQL 可以通过行锁、MVCC、连接池和后台进程处理更复杂的并发写入。也就是说，SQLite 并不是“低端”，而是把复杂性让给了应用和文件系统。
PRAGMA journal_mode = WAL; PRAGMA busy_timeout = 5000;
如果你的系统写入频率低、主要是本地读查询，SQLite 会非常舒服。如果有大量用户同时下单、评论、发送消息，服务器数据库更稳。
功能和运维能力也不同
PostgreSQL 在复杂 SQL、JSON、GIS、窗口函数、扩展生态上很强；MySQL 在 Web 生态、主从复制和常见业务场景里成熟；SQLite 的强项是小而完整，支持事务、索引、触发器、视图、全文搜索扩展，但没有内置用户权限、网络服务和复杂运维能力。
备份也不同。SQLite 可以复制文件，但最好在没有写入或使用在线备份 API 时做；服务器数据库通常有 dump、复制和 PITR 方案。把 SQLite 文件放到网络文件系统上多人写，是常见也危险的坑。
追问
SQLite 能不能用在线上 Web 服务？
可以，但要看写入模型。只读多、写入少的小服务、文档站、配置中心、边缘节点缓存都可以考虑 SQLite。需要持续高并发写入、复杂权限、多实例共享写库时，就不适合硬扛。取舍是 SQLite 能显著降低部署成本，但你要接受单写者和文件级运维边界。
为什么 PostgreSQL 更适合复杂业务？
PostgreSQL 有更完整的并发控制、查询优化器、类型系统、扩展机制和运维工具。复杂报表、地理信息、全文搜索、JSON 查询和多租户权限都能在数据库层处理得更系统。SQLite 也能做不少 SQL，但很多企业级能力需要应用自己补。边界是如果你的应用只是本地存储或轻量服务，用 PostgreSQL 反而可能增加维护负担。
从 SQLite 迁移到 MySQL/PostgreSQL 难吗？
中小项目通常可迁，但不要低估类型、SQL 方言和并发假设的差异。SQLite 的动态类型、INTEGER PRIMARY KEY、日期存储约定、部分 PRAGMA 都不能原样照搬。建议一开始就避免太多 SQLite 专属写法，关键表加清晰约束。踩坑点是迁移时才发现历史数据里混了文本数字、超长字段和不合法日期。
为什么很多测试环境喜欢用 SQLite？
它启动快、没有服务依赖、数据文件容易重建，很适合单元测试和本地开发。问题是测试通过不代表线上数据库一定没问题，因为锁模型、类型严格度和 SQL 方言可能不同。如果生产用 PostgreSQL，核心查询最好仍用 PostgreSQL 跑集成测试。SQLite 做测试替身的边界，是验证业务流程方便，但不能完全验证数据库行为。