生产环境中，SQLite 并没有一个绝对的“禁用容量线”，但官方建议当预期数据库超过 100GB 时，应评估是否转向客户端 - 服务器架构的数据库引擎。
先说结论：容量不是唯一指标，写并发和备份维护成本才是决定是否迁移的关键。
- 适合：读多写少、单节点部署、数据量在 100GB 以内的场景
- 重点看：写入频率是否频繁触发锁等待，以及全量备份耗时是否可接受
- 别忽略：网络文件系统（NFS）不支持 SQLite 锁机制，严禁放在共享存储上
现状评估与优化建议
在考虑迁移前，先确认当前数据库文件大小和写入负载，评估备份窗口是否满足业务要求。若决定继续使用，建议开启 WAL 模式以提高并发读性能，减少写锁阻塞。
# 查看 SQLite 文件大小
ls -lh your_database.db
# 进入 SQLite 命令行检查完整性
sqlite3 your_database.db "PRAGMA integrity_check;"
# 检查并开启 WAL 模式（注意：NFS/SMB 共享存储不支持）
sqlite3 your_database.db "PRAGMA journal_mode=WAL;"注意：WAL 模式在某些旧版本驱动或特定文件系统（如 NFS、SMB）上可能存在兼容性问题，务必确保数据库文件位于本地磁盘。
迁移触发信号与监控指标
当出现以下信号时，建议启动迁移评估：
- 应用日志频繁出现
database is locked或SQLITE_BUSY错误，且重试机制无法缓解。 - 全量备份耗时超过维护窗口，影响业务连续性。
- 单文件体积接近 100GB，且增长速率较快，VACUUM 操作导致长时间锁表。
数据迁移方案参考
若决定迁移至 PostgreSQL 或 MySQL，可参考以下工具链：
- pgloader：支持直接将 SQLite 数据迁移至 PostgreSQL，自动处理类型映射。
- 逻辑导出导入：使用
sqlite3 .dump导出 SQL 脚本，经处理后导入目标数据库。
# pgloader 示例命令
pgloader sqlite://./your_database.db pgsql://user@localhost/dbname高风险场景与规避
1. 共享存储锁失效：严禁将 SQLite 文件放在 NFS 或 SMB 共享目录，会导致锁机制失效和数据损坏。
2. 文件虚大：长时间未执行 VACUUM 可能导致文件占用磁盘高但实际数据不多，需在低峰期维护。
3. 并发写入锁等待：在高并发写入场景下强行使用 SQLite，必须实现应用层重试机制处理锁等待。
参考来源
SQLite 官方文档：When To Use SQLite
URL: https://www.sqlite.org/whentouse.html