你为什么要搬，
以及搬过来的代价

你的客户端不用改。kevy 说 RESP2 和 RESP3，实现了 206 条命令。把你现有的库指过来就行，代码不动，redis-cli 不换。没有新的 SDK 要接，也没有新协议要学。

所以真正要问的只有一句：你能换到什么。只有四样。如果这四样对你都没有价值，那就留在 Redis——它是一件极好的软件，为换而换，只是白白搭进去一个星期。

1. 它能跑在 Redis 跑不到的地方

   嵌进二进制，发到浏览器标签页，在一颗没有分配器的 Cortex-M 上启动。今天这些场合各要一层自己的存储、一套自己的 API；在这里，它们是同一个引擎、同一批命令。如果你曾经为客户端那边另写过一个缓存，这就是值得看一眼的理由。

2. 它顺带把搜索服务也替掉

   二级索引、物化视图、向量 KNN、BM25 全文检索都在引擎里——不是模块，不是 sidecar，也不是一份会慢慢和原数据对不上的副本。原本要跑 Redis 加一个搜索集群的团队，往往只需要跑一个东西。

   # look up by a field, not just by the key
   IDX.CREATE idx:city ON PREFIX user: FIELD city TYPE str KIND range
   IDX.QUERY  idx:city EQ osaka
   
   # vectors, in the same engine, over the same keys
   IDX.CREATE idx:sem ON PREFIX doc: FIELD vec TYPE vector KIND ann DIM 768 DISTANCE cosine
   IDX.QUERY  idx:sem KNN "<vector>" LIMIT 10

3. 你现在跑的那些操作，它更快

   同一台机器上对 Redis 8.10.1：GET 快 1.33×，SET 快 2.66×，INCR 快 2.05×。不过在你把这个当成理由之前，先把整张表看完——LPUSH 和 ZADD 只领先 10% 和 15%，如果 list 或者 sorted set 是你的热路径，那这就不是你该搬的理由。

4. 数据集不必再装进 RAM

   给 store 一个 RAM 预算，最冷的值就下沉到磁盘上一份可丢弃的 value log，访问时换回——冷键上每条命令不变，append-only 日志的持久化契约不动。RAM 决定你能放多少个键，磁盘决定你能放多少数据。这替掉的是「Redis 加一个单独的磁盘存储」的拆分——大 value、长尾负载不用再分家。诚实的边界：它默认关闭，v1 只下沉字符串和 hash（list、set、stream 留在热层），64 字节以下的值从不下沉——stub 会和值一样大。

   # kevy.toml
   [tiering]
   budget = "70%"      # or "4gb", or "auto"

# 1. dump what you want to move. it is a RESP file — readable,
#    diffable, and it streams rather than loading into memory.
kevy-cli export -p 6379 --prefix user: dump.resp
-> exported 41023 keys -> dump.resp

# 2. load it. --strict stops on the first error rather than
#    limping onward with a half-migrated keyspace.
kevy-cli import -p 6380 --strict dump.resp
-> imported 82046 ok, 0 errors, offset 4108331

# 3. prove they agree, rather than hoping.
kevy-cli digest -p 6379 user:
kevy-cli digest -p 6380 user:
-> 41023 keys 3bca92aa52269300     # the same hash, or you did not migrate

# an interrupted import resumes where it stopped:
kevy-cli import -p 6380 --resume dump.resp

从 Redis 导出，导入 kevy，再校验两边一致。下面每一条命令都真的跑过。

不要搬你的数据库。要搬的是它身上那一部分从来就不是数据库问题的东西。

会话。限流。功能开关。任务队列。还有那一行每个请求都要读、却从来没人拿去 join 的热点行。在大多数应用里，这些都住在 Postgres 里，而它们正是被敲得最狠的那些行——不是因为关系型数据库做不好，而是因为它们从来就不是提问。它们是查表。key 你早就知道了。

Postgres 最擅长的那些事，留给 Postgres——join、临时查询、分析，以及跨无关行的真隔离事务。kevy 接走对外服务的那条路径，让数据库喘口气。

而且单表的服务型读也能搬。用 TABLE.DECLARE 把类型化列、二级索引和复合 ORDER BY 路径声明一次——或者用 kevy-sql 直接编译你手上现成的 PG/MySQL schema 文件——单张表的读路径（索引化的 WHERE、余下的过滤、ORDER BY、翻页、COUNT）就编译到 kevy 索引上，查询期没有任何计划器。kevy-sql 是构建期的编译器，不是 SQL 引擎：join 和临时 SQL 被按名拒绝，它们留在 Postgres。这正是大多数应用真正在用 ORM 的那一部分。

红色那三行不是待办清单，是拒绝——kevy 不会长出 join，也不会长出优化器，因为把这两样做砸了，比不做还糟。每一种关系型负载，以及它在这里真实的代价，其中也包括那些诚实答案就是留在 Postgres 里的负载。

# 1. pick ONE workload. sessions are the usual first, because
#    nothing joins against them and losing one is survivable.

# 2. write to both for a week. reads still come from Postgres.
#    you are checking that the shapes match, not that it is fast.

# 3. flip reads to kevy. keep the dual write.
redis-cli SET session:$SID "$JSON" EX 3600

# 4. when it has been boring for a fortnight, drop the table.

# then do the next workload. rate limits, then queues, then
# whichever of your read paths a secondary index can answer.

不要一次性切换。一次只搬一种负载，让数据库继续做事实来源，然后测。