Pick any vector-database comparison published this year and it will argue about the same two numbers: recall at some k, and queries per second at that recall. Both live on the read path — the index is frozen, the vectors are already in, and the benchmark hammers it with lookups. It is the part that demos well and the part that fits in a chart.
Milvus 2.6 spent its most consequential engineering somewhere else entirely. It deleted the database's dependency on Kafka and Pulsar and replaced the entire streaming layer with a home-grown write-ahead log called Woodpecker. No headline recall number moved. What moved was the shape of what you have to run.
The queue was the tax#
Every earlier Milvus cluster shipped with a message queue underneath it. Writes did not go straight into a segment; they were appended to a log — Kafka or Pulsar — that gave Milvus durability and ordering and let its components consume the same stream independently. It is a clean design, and it is the design that made Milvus a genuinely distributed system rather than a single process pretending to be one.
It also meant that running Milvus meant running Kafka or Pulsar: a second distributed system, with its own brokers, its own partitions to rebalance, its own failure modes, its own pager. For a lot of teams that was the actual cost of the vector database — not the index, the queue.
Woodpecker's pitch is to make that tier disappear. In Milvus's words, 2.6 phases out external message queues "to reduce operational complexity and cost." The log is still there — a database this size needs a durable, ordered write path — but it is now Milvus's own, and it does not run on a broker.
Zero-disk means the log lives in the object store#
The load-bearing idea is where Woodpecker puts the log. Its "zero-disk" mode writes log data directly to object storage — S3, GCS, Alibaba OSS — and keeps only metadata in a distributed key-value store like etcd. No node in the write path owns durable state on a local disk. That is the whole trick, and it is why the message-queue cluster can go away: if the durable bytes live in the object store, the thing writing them can be stateless and disposable.
If the durable log lives in S3, the writer can be stateless — which is the entire reason the broker cluster gets to disappear.
There are two operating modes. A lightweight MemoryBuffer mode embeds a Woodpecker client that buffers incoming writes in memory and periodically flushes them to object storage — simple to deploy, ideal for standalone. A heavier quorum mode exists for setups that want stronger durability without waiting on every object-store round trip. Both share the same destination: the log's home of record is the object store, not a disk you provision.
The performance claims are loud — 450 MB/s in local-file mode at 1.8 ms latency, and 750 MB/s writing straight to S3, which Milvus pegs at about 68% of S3's theoretical ceiling and 5.8x Kafka and 7x Pulsar on the same bench. Treat those multipliers as vendor numbers on a vendor workload. The part worth believing is the direction: a WAL designed for object storage from the start beats one bolted onto brokers that were designed for local disks.
Why this is an agent story, not just a database story#
Classic retrieval-augmented generation is write-once. You ingest a corpus — docs, a wiki, a product catalog — build the index, and then read from it a million times. On that workload the queue tax is real but bounded; you pay it during ingestion and then mostly forget it.
Agent memory inverts the workload. An agent writes to its vector store constantly — every turn, every tool result, every observation it decides is worth remembering — and it writes in bursts that track how busy the agent is, not how big the corpus is. That is a different discipline from retrieval, and it carries its own bill; we have argued before that the read and write sides of agent memory should be priced separately, and the storage layer is where that split gets physical. The read path still matters, but the write path stops being a one-time ingestion job and becomes the steady-state hot path. Suddenly the durability log is not a background detail. It is the thing that has to keep up while a fleet of agents all append at once.
That reframes what "which vector DB" even means for agent builders. The usual axes for choosing between Qdrant, Milvus, and Weaviate — filtered-search strategy, hybrid retrieval, scale — all sit on the read path. The benchmark that matters here is not only recall@k on a static index; it is how much write tier you have to operate, and how quickly a vector you just wrote becomes searchable. Woodpecker is a direct bet on that question: it accepts a little more single-write latency — a round trip to object storage instead of a local fsync, softened by the memory buffer — in exchange for a write tier that scales like the object store and pages nobody.
The trade, stated plainly#
Nothing here is free. Putting the WAL on object storage means the durability of a just-acknowledged write is only as strong as your flush policy and mode, and the freshest writes may sit in a memory buffer for a beat before they land durably. If you need a hard, synchronous durability guarantee on every single append, an in-memory-buffered log on S3 is a different promise than a replicated broker, and you should read Woodpecker's consistency model before you assume they are interchangeable.
But for the workload agents actually generate — high-volume, bursty, tolerant of millisecond-scale freshness lag on a single memory — the trade is a good one. You give up a sliver of write latency and gain the deletion of an entire operated system. Milvus 2.6's other 2.6 headliners, RaBitQ quantization and tiered storage, are the read-path and cost stories, and they are real. Woodpecker is the quieter one, and it is the one that changes what running the thing feels like.
The lesson generalizes past Milvus. When you evaluate a store for agent memory, look past the recall chart to the write path: what has to be running for a write to be durable, and how fast that write shows up in a query. That is the axis agents are about to stress, and it is the one the benchmarks still don't print.
