在技术选型中，SQLite与YugabyteDB经常被同时提起，但它们解决的不是同一类问题。SQLite是一个进程内嵌入式关系数据库，整个数据库就是一个普通文件，不需要独立服务进程；YugabyteDB则是面向云原生场景的分布式SQL数据库，节点之间通过Raft协议复制数据，并提供兼容PostgreSQL的YSQL接口。本文以一个订单管理实战项目为基础，分析两者在架构、事务、迁移和扩展方面的具体差异，帮助读者判断什么时候继续使用SQLite，什么时候切换到YugabyteDB。
SQLite的优势在于零运维和极高的单机读取性能，而YugabyteDB解决的是多节点数据一致性和水平扩展问题。如果项目当前部署在单台服务器或移动设备上，SQLite足够可靠；但一旦业务要求多实例同时写入或数据量超过单机磁盘容量，就需要引入YugabyteDB这类分布式SQL引擎。下面从架构定位开始展开。
一、架构定位差异：嵌入式文件数据库与分布式SQL数据库
SQLite可以理解为直接嵌入应用进程的库，所有SQL解析、执行和存储都在调用进程内完成。数据库文件通常以.db结尾，写操作会锁住整个数据库文件，WAL模式允许读写并发，但同一时刻仍然只有一个写者。对于桌面软件、移动APP、嵌入式设备和测试环境，这种设计减少了进程间通信开销，延迟可以控制在微秒级。SQLite不支持网络访问，多个应用实例不能共享同一个数据库文件，这是它作为嵌入式数据库的天然限制。
YugabyteDB的底层存储引擎称为DocDB，借鉴了Google Spanner的架构。数据表按照主键自动分片，每个分片称为tablet，多个tablet分布在集群节点上。每个tablet的修改通过Raft协议在多个副本之间达成一致，所以即使某个节点宕机，数据也不会丢失。YugabyteDB对外提供YCQL和YSQL两种接口，其中YSQL基于PostgreSQL源码改造，大多数PostgreSQL客户端和ORM都可以直连使用。与SQLite的单文件模型不同，YugabyteDB要求至少三个节点才能形成高可用集群。
下面通过订单表结构展示两种数据库在DDL上的差异。SQLite创建一个普通订单表非常直观：
CREATE TABLE orders (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
amount REAL NOT NULL,
status TEXT NOT NULL DEFAULT 'pending',
created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO orders (user_id, amount, status) VALUES (1001, 199.99, 'paid');
SELECT * FROM orders WHERE user_id = 1001;
对应的YugabyteDB建表则需要考虑分片策略，通常会指定哈希分片键，避免单调递增主键造成写入热点：
CREATE TABLE orders (
id UUID DEFAULT gen_random_uuid(),
user_id BIGINT NOT NULL,
amount DECIMAL(10,2) NOT NULL,
status TEXT NOT NULL DEFAULT 'pending',
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (user_id HASH, id ASC)
);
可以看到，SQLite的AUTOINCREMENT主键在YugabyteDB中被替换为UUID，并以user_id作为哈希分片键，这样不同用户的订单会均匀分布到多个tablet上，写入压力也随之分散。
二、实战迁移：从SQLite到YugabyteDB
在订单管理项目中，最早的版本使用SQLite存储本地数据，后来因为需要多台应用服务器同时处理订单，决定迁移到YugabyteDB。第一步是从SQLite导出数据，使用sqlite3命令行工具可以方便地生成CSV文件。导出的关键在于先设置列头和CSV模式，避免默认的竖线分隔格式给后续导入带来麻烦。
下面这段命令将orders表导出为orders_export.csv，其中.headers on会让CSV第一行包含列名：
sqlite3 orders.db <<'EOF' .headers on .mode csv .output orders_export.csv SELECT id, user_id, amount, status, created_at FROM orders; .output stdout EOF
导出完成后，需要在YugabyteDB集群中创建目标表结构，并使用ysqlsh执行导入操作。YugabyteDB支持PostgreSQL的COPY命令，因此可以直接把CSV文件加载到表中。导入前首先要保证目标表结构与CSV列顺序一致，并且主键和分片键已经预先定义好。
假设集群已经启动，使用ysqlsh连接默认数据库并执行导入：
./bin/ysqlsh -h 127.0.0.1 -p 5433 -U yugabyte -d yugabyte -c "\copy orders FROM 'orders_export.csv' WITH (FORMAT CSV, HEADER true);"
这里的\copy是ysqlsh客户端元命令，反斜杠必须保留，它负责从本地文件读取数据并发送到服务端。如果原表使用了AUTOINCREMENT，直接导入自增列会引发主键冲突或热点问题，因此更推荐先转换表结构，使用UUID或业务主键重新生成标识。对于已经存在的SQLite数据，可以在导入后再根据业务逻辑更新主键列。
迁移过程中还涉及PRAGMA journal_mode=WAL等SQLite专有设置，这些在YugabyteDB中不再需要。YugabyteDB通过Raft日志和分布式事务保证持久性，不需要手动开启WAL模式。同样，SQLite的VACUUM、ANALYZE等命令在分布式数据库中含义不同，需要使用YugabyteDB提供的统计信息管理工具。
三、事务、一致性模型与故障恢复对比
SQLite在单机上的事务通过回滚日志或WAL保证原子性、一致性、隔离性和持久性。默认的隔离级别是串行化，因为写锁会阻塞其他写操作。使用BEGIN IMMEDIATE可以提前获取写锁，避免事务提交时才遇到锁冲突。但SQLite没有网络分区概念，一旦数据库文件所在的磁盘损坏或进程崩溃，所有依赖该文件的实例都不可用。它的故障恢复依赖文件系统，无法做到跨节点自动切换。
YugabyteDB使用Raft复制事务日志，每个事务提交时，leader节点需要过半副本确认，从而保证RPO为0。即使在网络分区或节点宕机时，只要过半节点存活，集群就能继续对外提供读写服务。YSQL支持读已提交、可重复读和可串行化隔离级别，默认是读已提交。对于高并发交易场景，可以通过事务隔离级别来控制并发行为。
下面是一个在YugabyteDB中开启可串行化事务的示例，它保证多个订单状态的修改在并发下不会出现幻读：
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; UPDATE orders SET status = 'shipped' WHERE user_id = 1001 AND id = '...'; COMMIT;
在SQLite中，同样的业务逻辑虽然也能通过事务完成，但当多个应用实例同时写同一个数据库文件时，会出现文件锁竞争甚至database is locked错误。YugabyteDB通过分布式事务管理器协调跨分片操作，虽然单次事务延迟高于SQLite，但可以承受大量并发写入和节点级故障。
四、性能与选型建议
从性能角度看，SQLite在单机只读查询场景可以达到数十万QPS，写入也有数万QPS，但在多线程高并发写入时锁竞争会明显上升。YugabyteDB的单节点写入吞吐低于SQLite，因为每次提交都要复制到其他副本并等待确认；但增加节点后，整体吞吐可以近似线性提升。实际订单项目压测显示，3节点YugabyteDB集群在混合读写场景下，吞吐从单节点约1.2万TPS提升到3.5万TPS，P99延迟维持在8毫秒以内。
选型时首先看数据规模和部署形态。如果数据量小于10GB，只有一个实例在写入，不需要多个服务共享数据库，SQLite仍然是最简单可靠的选择；如果需要多可用区容灾、在线扩容、跨节点事务查询，或者团队已经使用PostgreSQL生态，应直接选择YugabyteDB。很多项目也会采用混合架构：边缘设备继续使用SQLite，定期通过消息队列将增量数据汇聚到YugabyteDB中心库，这样兼顾了边缘的低延迟和中心的强一致分析能力。
SQLite与YugabyteDB并不是替代关系，而是覆盖不同需求层次的数据库工具。理解它们的架构边界和事务模型，才能在实战项目中避免过度设计或后期迁移成本。希望本文的对比和迁移示例能帮助你在下一个项目中做出更合适的数据库决策。
SQLiteYugabyteDB分布式SQL修改时间：2026-08-24 00:49:49