一、前言
在本地工具、小型单体应用、轻量服务开发场景中，SQLite 凭借零部署、零运维、开箱即用的特性，成为使用率极高的嵌入式关系型数据库。对于低并发、小数据量的单机项目，SQLite 可以极大提升开发效率、降低落地成本。
但绝大多数开发者仅停留在"能用、够用"的阶段，并不了解 SQLite 底层架构带来的原生短板。一旦业务数据量上涨、并发请求变高、多模块多节点部署，就会陆续出现锁冲突、查询卡顿、表结构无法迭代、并发写入超时等各类线上问题。
本文完全基于通用后端技术原理 ，不涉及任何行业业务、项目私有代码与方案，系统性梳理 SQLite 核心特性、WAL 并发优化、DDL 语法致命缺陷、兼容升级方案，并对比 SQLite 与 PostgreSQL 的适用场景，最后给出轻量单机架构 vs 分布式重型架构的取舍思路，给开发者提供清晰的数据库选型与迁移参考。
二、SQLite 核心特性与 WAL 并发优化机制
2.1 SQLite 核心轻量化优势
SQLite 是典型的文件型嵌入式数据库，整个数据库仅对应一个磁盘文件，和 MySQL、PostgreSQL 这类服务型数据库有本质区别，核心优势集中在轻量化与低成本：
-
无独立服务进程：无需安装数据库服务、无需配置启动项，直接拷贝数据库文件即可完成部署，完美适配本地客户端、桌面工具、单机小型服务。
-
零运维成本：无账号权限、无集群配置、无主从同步、无连接池复杂管控，小型项目几乎无需任何维护。
-
跨语言兼容性强：Python、Java、C/C++、Go 等主流开发语言均有成熟稳定的驱动，接入成本极低。
2.2 WAL 预写日志：单机并发的唯一优化方案
SQLite 默认采用读写互斥机制，同一时刻只能读或者只能写，并发能力极差，多请求场景下极易阻塞。
开启 WAL（预写日志）模式 后，SQLite 实现了基础的读写分离并发，是单机场景下唯一有效的性能优化手段：
-
写操作不再直接覆盖主数据库文件，所有写入操作先落地到独立的 WAL 日志文件；
-
读操作直接读取原始主库文件，读写互不阻塞，大幅提升单机并发吞吐量；
-
系统空闲、 checkpoint 触发时，自动将 WAL 日志合并同步至主库文件，保证数据一致性。
核心局限 ：WAL 仅优化单机单实例读写并发，无法解决多进程、多服务、分布式场景下的写入锁冲突，高并发集群场景下依然存在严重瓶颈。
三、SQLite DDL 语法缺陷与通用兼容升级方案
3.1 原生 DDL 能力的致命短板
SQLite 为极致精简内核，大幅阉割了表结构变更能力，和主流企业级数据库相比存在明显硬伤，也是长期迭代项目最大的坑点：
-
不支持通过 ALTER TABLE 修改字段名称、调整字段数据类型；
-
不支持直接删除数据表指定字段；
-
不支持动态新增主键、外键、唯一索引等表约束；
-
所有复杂表结构变更，只能通过「新建临时表 - 数据迁移 - 删除旧表 - 重命名临时表」的迂回方式实现，迭代成本极高，且容易引发数据风险。
反观 MySQL、PostgreSQL，原生支持在线增删字段、修改字段属性、动态添加约束，非常适配业务长期迭代。
3.2 通用增量升级兼容方案
SQLite 没有内置语法判断表、字段、索引是否存在，重复执行创建语句会直接抛出异常，导致升级脚本中断、服务启动失败。
行业通用标准解决方案：全局 try-except 异常捕获封装升级逻辑 。在执行新增字段、索引、约束的 SQL 时，捕获重复创建异常，结构已存在则自动跳过，保证升级脚本可重复执行、适配多版本迭代、批量部署，规避线上升级报错问题。
3.3 主流数据库 DDL 能力横向对比
| 数据库操作 | MySQL | PostgreSQL | SQLite |
|---|---|---|---|
| 创建/删除数据表 | 支持 | 支持 | 支持 |
| 新增数据表字段 | 支持 | 支持 | 支持 |
| 修改字段名、字段类型 | 支持 | 支持 | 不支持 |
| 删除已有字段 | 支持 | 支持 | 不支持 |
| 动态添加表约束 | 支持 | 支持 | 不支持 |
四、SQLite 单机架构的天生局限
SQLite 的定位是本地嵌入式数据库，底层基于文件锁实现数据隔离，架构上完全不支持分布式扩展，业务扩张后瓶颈会全面暴露：
-
高并发写入锁竞争严重：多进程、多请求同时写入时会出现大量锁等待、写入超时，高并发场景极易丢请求、报错。
-
无任何分布式能力：不支持主从同步、读写分离、分库分表、多节点数据同步，无法多机器共享一套数据库。
-
海量数据性能断崖式衰减：单文件存储全部数据，单表数据量达到百万级后，索引查询、分页统计、聚合查询速度明显下滑，无原生分区优化能力。
-
不适合多模块架构：多服务、多组件同时读写同一数据库文件时，锁冲突概率剧增，完全无法适配微服务、多系统集成架构。
五、SQLite 迁移 PostgreSQL 全维度改造分析
当业务突破单机轻量阈值，出现数据量大、并发高、多节点部署等需求时，PostgreSQL 是最优替代方案。下面从适用场景、部署、运维、工作量全方位分析改造成本。
5.1 适合升级 PostgreSQL 的业务场景
-
多节点、多分支机构分布式架构，需要多服务器数据统一汇总、集中查询管理；
-
单表数据量达到数十万、百万级别，SQLite 查询卡顿、接口响应变慢；
-
多服务、多第三方系统同时读写数据库，频繁触发文件锁冲突、写入失败；
-
业务需要自动分区、复杂索引、完善的外键约束、在线表结构变更等高级数据库能力。
5.2 迁移成本横向对比
1）部署复杂度
SQLite：单文件模式，复制即用，零部署、零配置。
PostgreSQL：需独立部署数据库服务、配置账号权限、开放端口、配置定时备份、优化参数，部署流程完整且繁琐。
2）长期运维成本
SQLite：零运维，无需专人监控维护。
PostgreSQL：需要持续监控慢查询、连接数、磁盘占用、性能指标，故障时需处理连接异常、数据同步问题，需要基础运维支撑。
3）改造工作量
完整迁移流程：安装 PostgreSQL 服务 → 导出 SQLite 全量数据 → 数据清洗导入 → 改造项目数据库连接与 SQL 适配 → 全业务回归测试，哪怕小型项目也需要完整的测试闭环。
六、架构取舍：轻量巧但脆 VS 重型稳但重
SQLite 轻量架构与 PostgreSQL 分布式架构没有绝对优劣，核心选型依据是当前业务体量 + 未来3年迭代预期。
6.1 SQLite 轻量架构（巧但脆）
架构组成：单文件数据库 + 简单单体业务代码，无集群、无分片、无主从。
优势：开发极速、部署极简、零运维、小型单机场景响应高效，快速落地业务。
短板：扩展性有明确上限，不支持高并发、海量数据、分布式场景，业务扩张后重构成本极高。
适配场景：本地桌面工具、单机门店程序、低流量内部小系统、临时演示项目。
6.2 PostgreSQL 重型分布式架构（稳但重）
架构组成：独立数据库服务、支持主从读写分离、数据分区、多节点集群同步、完善事务与约束。
优势：并发能力强、海量数据存储稳定、表结构迭代灵活、支持复杂业务场景、长期迭代稳定性拉满。
短板：部署复杂、前期配置工作量大、需要持续运维成本。
适配场景：多节点连锁系统、SaaS 云端平台、高并发互联网服务、长期迭代的正式商业项目。
七、总结
1、SQLite 是极其优秀的嵌入式轻量数据库，在小数据、低并发、单机本地场景下性价比拉满，但文件锁机制、残缺的 DDL 语法、无分布式能力是无法规避的底层短板。
2、WAL 日志、异常捕获升级脚本可以缓解部分问题，但只能"治标"，无法解决高并发、海量数据、多节点部署的核心瓶颈。
3、架构最佳实践：项目前期用 SQLite 快速落地，通过数据库抽象层解耦代码，提前降低后续迁移成本；当业务出现百万级数据、高并发写入、多节点部署需求时，及时迁移至 PostgreSQL 企业级数据库。
4、选型核心逻辑：小场景追求开发效率 ，大场景追求稳定扩展，不盲目过度设计，也不忽视长远架构瓶颈。