用 SQLite 替代 Redis？别笑，认真的

最近看到一个有趣的趋势：越来越多的项目开始用 SQLite 来做一些原本 Redis 干的活。听起来离谱？让我们理性分析一下。

背景

这股风潮的推动者主要有：

• Litestream：SQLite 的流式复制工具
• LiteFS：Fly.io 搞的分布式 SQLite
• Turso/libSQL：SQLite 的边缘计算分支
• Rails 8：默认用 SQLite 做缓存和队列

当 DHH 在 Rails 8 里把 SQLite 作为缓存后端的默认选项时，这个话题彻底火了。

SQLite 能替代 Redis 的场景

1. 缓存

CREATE TABLE cache (
    key TEXT PRIMARY KEY,
    value BLOB,
    expires_at INTEGER
);

CREATE INDEX idx_cache_expires ON cache(expires_at);

配合 WAL 模式，SQLite 的读性能非常强：

• 单机读 QPS 可以到 10 万+
• 延迟在微秒级别（本地文件，无网络开销）
• 不需要序列化/反序列化的网络传输

2. 会话存储

用户 session 数据通常读多写少，完美适合 SQLite：

CREATE TABLE sessions (
    id TEXT PRIMARY KEY,
    data JSON,
    created_at INTEGER,
    updated_at INTEGER
);

3. 简单队列

CREATE TABLE jobs (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    payload JSON,
    status TEXT DEFAULT "pending",
    created_at INTEGER,
    locked_at INTEGER
);

-- 取任务（原子操作）
UPDATE jobs SET status = "processing", locked_at = unixepoch()
WHERE id = (SELECT id FROM jobs WHERE status = "pending" ORDER BY id LIMIT 1)
RETURNING *;

SQLite 替代不了 Redis 的场景

1. 分布式场景

Redis 天生支持主从复制、哨兵、Cluster。SQLite 是单机数据库，虽然 LiteFS 和 Turso 在努力，但成熟度差距还很大。

2. 发布/订阅

Redis 的 Pub/Sub 和 Streams 是实时消息的利器。SQLite 没有内置的通知机制，轮询不优雅。

3. 高写入并发

SQLite 的写入是串行的（WAL 模式下一个写者 + 多个读者）。如果你的场景是高频写入（比如计数器、限流），Redis 的内存操作快得多。

4. 复杂数据结构

Redis 的 Sorted Set、HyperLogLog、Bitmap 这些数据结构，用 SQLite 模拟成本很高。

性能对比（本地单机）

操作	Redis	SQLite (WAL)
点查 GET	~50μs	~5μs
写入 SET	~50μs	~100μs
批量读	~200μs (pipeline)	~50μs
范围查询	~100μs	~20μs

注意：Redis 的延迟包含网络往返（即使是 localhost 也有 ~40μs），SQLite 是纯本地文件操作。所以在本地读场景下，SQLite 反而更快。

什么时候该用 SQLite 替代 Redis？

✅ 适合替代：

• 单机部署的小中型应用
• 读多写少的缓存场景
• 想减少运维复杂度（少一个服务）
• 边缘计算/嵌入式场景
• 开发环境

❌ 不要替代：

• 分布式系统
• 高写入并发
• 需要 Pub/Sub 功能
• 需要 TTL 自动过期（SQLite 需要自己实现清理）

我的实践经验

在一个日活 5000 的内部工具项目中，我把 Redis 缓存层换成了 SQLite：

• 内存占用从 200MB 降到 50MB
• 部署从 2 个容器变成 1 个
• 响应时间反而降了 30%（省了网络往返）
• 运维成本约等于零

当然，这个项目规模不大。如果是日活百万的服务，我还是老老实实用 Redis。

结论

技术选型不是信仰之争。SQLite 和 Redis 各有各的甜蜜点。关键是理解你的场景，选择最合适的工具。

如果你的应用是单机部署、读多写少、不需要分布式特性，那 SQLite 可能是一个更简单、更高效的选择。试试看，你可能会惊喜。