On 24 August this index put a dated call on the record: object storage reclassifies from cold persistence to AI's active memory tier, and I/O topology rather than capacity becomes the axis storage products compete on. The revision conditions were explicit — we said we would back off if S3-tier latency proved too slow for production TTFT budgets, or if NAND pricing normalised enough that local NVMe undercut the remote-tier arithmetic.
October did not trigger either of those. It did something more awkward and more useful: it confirmed the call decisively on one side of the stack and produced a fourth consecutive window of nothing on the other.
Two major releases landed in the same month, from projects that have no particular reason to agree with each other, and both of them made the same architectural concession. A third, the one the call actually depends on, did not.
The vector engine stopped pretending it owned the data
Milvus moved from the 2.6 line to 3.0.3, and the jump is a rewrite rather than a version bump. The engine is now positioned as the kernel of a lake-native architecture, built on a new storage layer internally designated Storage V3 ("Loon") that aligns vector storage with open lakehouse principles rather than a proprietary internal format.1
Read that as a concession, not a feature. A vector database that rebuilds itself around lake-native storage is saying that the object store is the source of truth and that its own indexes are a derived, rebuildable cache over it. That is precisely the shape this index has tracked under Decoupled Vector Search — and it is the same motion we described in July when the standalone RAM-first vector niche started narrowing.
The supporting changes are consistent with that reading rather than decorative. The write-ahead log, Woodpecker, can now be deployed as an independent service instead of being embedded in other nodes, which is what you do when the write path has to scale and fail separately from query.1 The previously distinct Index Node and Data Node merge into one component, cutting a layer of distributed-deployment complexity.1 Asynchronous off-peak segment compaction is engineered specifically for the file fragmentation that object storage produces.1
The migration terms deserve attention because they are conditional in a way release notes usually are not. Upgrading 2.6 → 3.0 preserves backward compatibility and permits rollback only while Storage V3 stays disabled, which is why it ships disabled by default. Enable it and the rollback path is permanently severed.1 GPU images move to CUDA 12.9, dropping Ubuntu 20.04 compatibility outright, and the new index versions are opt-in behind manual version elevation.1 This is a project that knows it is asking operators to cross a one-way door and has at least signposted it.
Out-of-core stopped being the exception
Polars reached 2.0.0 on 5 October — confirmed as the final stable release, superseding the 2.0.0-rc.1 and rc.2 candidates, which matters because a reference index that cites a release candidate as stable has done the opposite of its job.2
The headline change is that the out-of-core spill-to-disk engine is on by default, initiating when memory crosses roughly 80% of available RAM against a default 64 GB disk budget.2 Stated as a feature that is unremarkable. Stated as an architecture it is the same concession Milvus made from a different direction: memory is a working set, the durable tier is somewhere else, and crossing between them is a normal operating condition rather than a failure.
The practical consequence runs against the distributed-compute default. Guaranteed out-of-core execution means complex joins and aggregations over large Parquet datasets on S3 can run on one vertically scaled instance instead of a cluster. That is the single-node-pulls-from-object-storage pattern this index has tracked since the lakehouse guides were written, and 2.0 makes it the supported path rather than the lucky one.
Two details matter for anyone on the Iceberg path. Distributed Iceberg sinks now require pyiceberg ≥ 0.12 on worker nodes, and Parquet ENUM types are read strictly as strings.2 The release also deprecates cut and qcut in favour of bin_intervals and removes POLARS_STREAMING_CHUNK_SIZE entirely.2 Budget it as a migration.
The layer the call actually rests on did not move
Here is the part that does not support the thesis, printed at the same size as the parts that do.
vLLM went 0.30.0 → 0.32.0 and shipped real work: Model Runner V2, GPU n-gram speculation, Elastic EP with drain-then-commit scaling, and low-precision NVFP4 KV cache support for SM8x and SM12x.3 There is no documented evidence in that changelog that vLLM natively offloads or persists the KV cache to an object-storage tier. True disaggregated serving writing KV state to S3 remains absent.3
That is the fourth consecutive window in which the specific clause — KV-cache-on-object-storage as a generally available, priced product — has produced no new data. Not a slower yes. No data. The adjacent progress is genuine and it keeps not being the thing we called. Cold-start work, per-GPU weight caches and NVFP4 quantisation all make the hot tier cheaper; none of them make the cold tier part of the serving path.
The honest reading is that the KV-cache clause and the storage clause are decoupling. Vector search and analytical query are converging on object storage because their access patterns tolerate it. Inference has not, because a cache miss that costs a round trip to S3 lands directly in a TTFT budget that nobody has yet shown is survivable outside long-context niches. KV-Cache Disaggregation and LMCache remain the nodes to watch, and neither moved this month in the direction the call requires.
Scoring it
The 2026-08-24 call stands, confirmed for the storage and query layers and unscored for inference, and we are splitting it rather than averaging it. Averaging would let two confirmations carry a clause that has produced nothing since July, which is how a call quietly becomes unfalsifiable.
What would change this. For the inference clause: a managed, priced product reaching GA with KV-cache persistence to an S3-compatible tier, or a production framework publishing cache-hit latency inside a stated TTFT budget. For the storage clause, a refutation would look like Milvus operators declining Storage V3 at scale, or Polars users finding the 80% spill threshold unusable in practice and pinning it off — both of which are observable, and neither of which we have evidence for yet.
One closing note on method. The version deltas behind this post came from a staleness sweep that had been reporting 14 stale nodes when the real number was 30; it was reading the highest version-shaped number on a line rather than the one each node actually claims, which inflated our own recorded versions until genuinely stale nodes compared as current. That is fixed, the sweep now runs without an API key, and the three majors it surfaced were each checked by hand against upstream tags before anything here was written. The instrument was wrong in the direction that produces false comfort, which is the direction worth checking.
Works cited
Footnotes
-
Releases — milvus-io/milvus. Milvus 3.0.3; Storage V3 ("Loon"), Woodpecker WAL as an independent service, Index/Data Node merge, and the conditional rollback terms. ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Releases — pola-rs/polars. Polars 2.0.0, published 5 October 2026, superseding 2.0.0-rc.1 and rc.2; out-of-core spill enabled by default, pyiceberg ≥ 0.12 requirement, and the listed breaking changes. ↩ ↩2 ↩3 ↩4
-
Releases — vllm-project/vllm. vLLM 0.32.0; Model Runner V2, Elastic EP, NVFP4 KV cache. No object-storage KV-cache persistence documented in the 0.30.0 → 0.32.0 range. ↩ ↩2