TiKV v8.5.7 arrived on July 9, 2026, and it is packing some genuinely clever upgrades under the hood. The distributed key-value engine that powers TiDB just got a lot smarter about where it puts its data, how it handles bad timestamps, and how much control you have over resource isolation.
But before we get into the juicy stuff, let us set the stage for anyone who hasn’t met TiKV yet.
What Is TiKV, and Why Should You Care?
TiKV (which stands for “Titan Key-Value”) is an open-source, distributed, transactional key-value database. Think of it as the storage engine brain that sits underneath TiDB, a MySQL-compatible distributed SQL database. If TiDB is the friendly face that speaks SQL to your application, TiKV is the relentless warehouse worker in the back who actually moves all the boxes.
TiKV is what happens when you take Google’s Spanner paper, build it in Rust, and make it work for mere mortals.
What problem does it solve? Horizontal scalability for transactional workloads. Traditional databases choke when you try to scale them across multiple machines while keeping ACID guarantees. TiKV uses the Raft consensus algorithm to replicate data across nodes, so you get strong consistency without the single-point-of-failure headache. No more “the database server died, so everything is on fire” Tuesdays.
Who uses it? Companies running large-scale OLTP (online transaction processing) workloads — think e-commerce platforms, financial services, and SaaS products that have outgrown a single PostgreSQL or MySQL instance. TiKV is a CNCF graduated project, which means it has earned its battle scars in production at scale.
Why care about v8.5.7 specifically? This release brings CPU-aware hot Region scheduling, partial indexes, a whole new set of resource control knobs, and a behavior change around timestamp safety that you need to know about before upgrading. Let’s dig in.
What’s New in TiKV v8.5.7
CPU-Aware Hot Region Scheduling
Here is the problem this solves: in older versions, TiKV’s hot Region scheduler balanced read load by looking at query rate (QPS) and byte throughput. That sounds reasonable, but different queries have wildly different CPU costs. A query that scans a million rows costs more CPU than one that fetches a single key, even if both count as “one query” in the QPS metric. So you could have perfectly balanced QPS numbers while one TiKV node is sweating bullets and another is basically asleep.
Starting from v8.5.7, TiKV now reports read CPU usage for hot Regions in its store heartbeats. PD (Placement Driver, the brain that decides where data lives) can now use actual CPU usage as a scheduling dimension. It’s like your load balancer finally getting a thermometer instead of just counting requests.
# PD scheduler configurations now include CPU-related options:
# min-hot-cpu-rate — minimum CPU rate to consider a Region "hot"
# cpu-rate-rank-step-ratio — controls how Regions are ranked by CPU usageThis is a real improvement for anyone running mixed workloads where query complexity varies wildly. PD PR #5718 and TiKV PR #19373.
Partial Indexes
This one is a TiDB feature, but since TiKV is the storage layer, it directly impacts how TiKV stores and maintains index data. Partial indexes let you create an index that only covers rows matching a specific condition. Instead of indexing every row in a table, you index only the ones you actually query.
Imagine you have a users table with 50 million rows, but you only ever query active users (where status = 'active'), which is maybe 5 million rows. With a partial index, you skip indexing the other 45 million rows entirely. That means less storage, faster writes (fewer index entries to maintain on INSERT/UPDATE/DELETE), and smaller indexes that are faster to scan.
-- Only index active users instead of all users
CREATE INDEX idx_active_users ON users (email) WHERE status = 'active';
-- Partial unique constraint: emails must be unique among active users only
CREATE UNIQUE INDEX idx_unique_active_email ON users (email) WHERE status = 'active';TiDB’s optimizer will automatically choose a partial index when your query predicates match or imply the index predicate. Supported predicate operators include =, !=, <, <=, >, >=, IS NULL, IS NOT NULL, and IN with constant values. TiDB PR #62664.
New Resource Control and Admission Control Options
TiKV v8.5.7 ships a significant set of new configuration options under resource-control. These give you fine-grained control over how TiKV handles resource contention between foreground (user) traffic and background (compaction, GC) tasks.
- Read admission control (
enable-read-admission-control) — hold read requests when TiKV is overloaded instead of letting them pile up and cause latency spikes. - Write admission control (
enable-write-admission-control) — same concept but for writes. - Fair scheduling (
enable-fair-scheduling) — two-phase RU-based fair scheduling for read requests across resource groups. - Background traffic throttling — new options like
bg-cpu-throttle-threshold(default 60%),bg-compaction-pressure-threshold(default 70%), andbg-write-io-floor/bg-write-io-ceilingto control how much I/O background tasks can consume. - Foreground protection —
fg-cpu-throttle-threshold(default 70%) activates full foreground traffic protection when CPU crosses this line. - Historical RU baselines —
historical-usage-window-mins(default 15) defines the sliding window for computing per-resource-group baselines.
This is TiKV growing up as a multi-tenant storage engine. It’s not just about raw throughput anymore — it’s about fairness and predictability when multiple workloads share the same hardware. TiKV PR #19607.
Top SQL Gets Network and I/O Metrics
TiDB Dashboard’s Top SQL feature used to identify expensive queries based only on CPU metrics. That left a blind spot: what if your bottleneck isn’t CPU but network traffic or storage I/O? Those were invisible.
Now you can enable TiKV Network IO collection (multi-dimensional) in the Top SQL settings and see Network Bytes and Logical IO Bytes per TiKV node. You can analyze these across dimensions including By Query, By Table, By DB, and By Region. This is controlled by the new resource-metering.enable-network-io-collection config option (defaults to false, so you have to opt in).
# Enable in TiKV config:
[resource-metering]
enable-network-io-collection = trueMax Timestamp Safety: Rejection by Default
This is the most important behavior change in v8.5.7. Previously, when TiKV detected an invalid max_ts update (a timestamp that shouldn’t exist), it would just log a warning and continue. That’s a safety risk — invalid timestamps can break transaction isolation guarantees.
Now, TiKV rejects invalid max_ts updates by default instead of silently logging them. If you have an older application or tool that relies on the log-only behavior, you need to know about this before upgrading. You can revert to the old behavior by setting:
[storage.max-ts]
action-on-invalid-update = "log"The default is now "error", which means TiKV returns an error and stops processing the request. This is the right default — failing loudly is better than failing silently when transaction safety is on the line. TiKV PR #19755.
Fail-Fast on Disk I/O Hangs
If a TiKV node’s disk I/O hangs (think: a failing SSD or a storage controller meltdown), the node used to hang along with it, causing cascading timeouts across the cluster. Now TiKV will automatically exit when it detects disk I/O hangs, triggering a faster failover to healthy replicas.
This is the kind of feature you never want to need, but when you do need it, it saves your cluster from a slow, painful death. TiKV PR #19626.
TiCDC Table Routing
The new TiCDC architecture now supports table routing — you can map upstream tables to different downstream database or table names using target-schema and target-table in the sink dispatchers configuration.
# In changefeed sink config:
[sink.dispatchers]
target-schema = "analytics_db"
target-table = "events_merged"This is useful when downstream naming conventions differ from upstream, or when consolidating multiple source databases into one target. TiCDC PR #4655, PR #4941, PR #4702.
Per-User Connection Limits
TiDB now supports limiting the number of connections a single user can establish to a single TiDB server instance via the new max_user_connections system variable. You can also set it per-user in CREATE USER statements:
CREATE USER 'api_service'@'%' WITH MAX_USER_CONNECTIONS 100;This prevents one user from consuming all available connections and starving everyone else. TiDB PR #59203.
Behavior Changes to Watch Before Upgrading
Beyond the features above, there are several default value changes that will affect your cluster on upgrade:
- Optimizer fix control 52869 is now enabled by default — the optimizer will consider IndexMerge automatically when alternative indexes exist. This could change query plans in some cases.
- tidb_auto_analyze_concurrency default changed from 1 to 3 — statistics collection will be faster but use more resources.
- tidb_sysproc_scan_concurrency default changed from 1 to 4 — internal scan operations will be faster.
- tidb_auto_build_stats_concurrency default changed from 1 to 2.
- Telemetry is deprecated —
tidb_enable_telemetryandenable-telemetryconfig are now deprecated.
If your cluster was upgraded from an earlier version, these system variable defaults remain unchanged after upgrade. Only freshly deployed v8.5.6+ clusters get the new defaults.
Under the Hood: Rust Compiler Upgrade
TiKV’s Rust compiler jumped from nightly-2023-12-28 to nightly-2025-02-28. That is over a year of Rust language and compiler improvements flowing directly into TiKV’s performance. Not a feature you can see, but one you might feel in throughput and latency.
Security and Bug Fixes
This release also includes several stability improvements:
- Memory management fixes for resolved_ts, raft-engine, raft message queues, and Raft log retention — these address memory growth issues in long-running clusters.
- Third-party dependency upgrades to address known vulnerabilities (TiKV PR #19713).
- Automatic fail-fast exit on disk I/O hangs, as mentioned above (TiKV PR #19626).
The full list of 29 TiKV issues addressed in this release can be found on the official release page.
TiKV v8.5.7 is a meaty release for anyone running TiDB at scale — CPU-aware scheduling, partial indexes, resource control, and timestamp safety make this worth the upgrade planning.
