Vector Database Comparison 2026: Pinecone vs. Milvus vs. Weaviate

What changed in Weaviate 1.38.8?

Weaviate 1.38.8, released July 29, is a non-breaking patch release. The release body lists no headline breaking changes and no broad new feature set, but it does ship one opt-in query path plus fixes that matter during batch ingestion, shard loading, backups, and Japanese tokenization.

The most useful addition is batched inverted-index evaluation for ContainsAny, ContainsAll, and ContainsNone under one consistent view. It is guarded by the runtime-overridable QueryBatchedContainsEnabled setting, so treat it as a controlled rollout rather than an automatic performance claim. The same release adds cross-property BM25 AND_CROSS matching and reduces allocation pressure in several storage paths.

• Batch writes report shard errors at every affected position. A failed shard lookup no longer leaves the rest of a batch group looking successful, and the panic handler now writes errors to the panicking group's own positions instead of risking another tenant's result slots.
• Loading-shard reads are consistent. FetchObjects no longer rejects every read while a shard is loading when replication is disabled; exercise this path during a rolling upgrade if your cluster reads during load.
• KagomeJa custom dictionaries no longer have an asymmetric throttle. The missing acquire/release pairing could hang a tokenizer goroutine. Audit TOKENIZER_CONCURRENCY_COUNT; zero, negative, or non-numeric values now warn and fall back instead of creating a zero-capacity or invalid throttle.
• Backup and dependency hygiene changed. Restores from legacy formats stopped years ago are removed, successful backup halts reset their inactivity deadline, and the x/net and x/text dependencies receive the release's CVE bumps.

Before upgrading, run a multi-tenant batch-ingestion failure test, a restore drill using a backup from the current format, and a sustained Japanese custom-dictionary workload. The vector database backup and restore playbook gives the restore test its own checklist, while the multi-dimensional retrieval guide is the better companion for validating the cross-property search behavior. If you use the new Contains path, enable it in a canary and compare query correctness before widening the rollout.

The 1.38.7 to 1.38.8 diff is the source for the individual fixes. It publishes no performance numbers, so use your own query mix and tenant distribution rather than substituting a release-note claim for a benchmark.

What changed in Weaviate 1.38.7?

Weaviate 1.38.7, released July 27, is a production patch with no breaking changes and no new features. Its 23 fixes target replica correctness, query safety, shutdown cleanup, and allocation pressure. The release headline is a fix that prevents a search result from being reused as a read-repair payload.

The patch also rejects non-object GraphQL variables instead of panicking, makes multi-vector insertion idempotent, cleans stale LSMKV registry entries on every teardown path, and prevents nil-pointer panics during replica file walks. Dependency bumps for golang.org/x/net and golang.org/x/text address CVE-2026-46600 and CVE-2026-56852.

Teams pinned to 1.38 should move to 1.38.7, run a replica read-repair test, and repeat a restore drill using the vector database backup and restore playbook. If your retrieval stack feeds a training or evaluation loop, verify that the patch does not change the data-quality signal carried into the AI/ML pipeline observability layer. Multi-vector users should also replay image-plus-text queries from the multimodal monitoring guide, because the idempotence fix sits directly on that write path.

Vector databases have become the connective tissue of production AI systems.

This is not another benchmark table with p99 latency numbers taken from marketing materials. This is a practitioner's guide to choosing the right vector database based on your actual constraints: team size, scale, operational maturity, and budget. If your retrieval workload is moving past single-vector cosine search into hybrid, multi-modal, or multi-tenant-routed scenarios, the multi-dimensional AI retrieval 2026 guide maps the query patterns that sit on top of whatever vector store you pick here — and is the right next read after this comparison. Once the choice is made, the operational cost of running it shows up in two places: GPU memory pressure during compaction (instrumented via the patterns in the GPU monitoring for AI inference guide) and the steady-state recall that determines whether retrieval is actually working (covered by the RAG observability guide). For the database of choice, the backup and restore operational playbook is in the backup and restore guide for vector databases.

Why Your Vector Database Choice Matters More Than You Think

Most teams treat the vector database as a commodity. They pick one based on a tutorial they followed or a tweet they read and move on. This is a mistake. The vector database is the retrieval layer that determines whether your RAG pipeline actually answers the question your users are asking. Picking the right database is the first step, but it does not stop there — once RAG is in production, you have to instrument the retrieval surface (recall, context utilization, faithfulness) to know whether it is working, and the RAG observability 2026 guide covers the metrics and alert thresholds that turn a vector DB choice from "we picked Pinecone" into "we know our retrieval is hitting target recall on a Monday morning."

A poor choice manifests as:

• Slow embedding queries that add 200-400ms of latency to every RAG retrieval call.
• Low recall that causes the model to answer from the wrong context — your users do not know why the model is confidently wrong.
• Unpredictable costs that scale super-linearly with your user base.
• Engineering time spent on Operational Theater rather than product features.

How do the three vector database contenders compare at a glance?

Before the deep dive, here is the at-a-glance comparison table. If you have already made the call and want the implementation playbook for the one you picked — backup cadence, restore drills, multi-region replication topology — the backup and restore guide for vector databases is the next read; the operational costs below are exactly what that playbook optimizes against.

Pinecone Serverless

What It Is

Pinecone Serverless is a managed vector database that handles all infrastructure decisions for you. It scales automatically based on query volume and data size, and you pay per query — not for provisioned capacity. The serverless architecture was a deliberate response to the operational complexity that plagued early Milvus deployments.

Performance Characteristics

Pinecone's performance is consistent and predictable. Because it runs on a purpose-built serving layer, you get single-digit millisecond p99 latencies for most retrieval queries at moderate scale (under 100M vectors). The serverless architecture means that cold starts are not your problem — Pinecone handles seasonal traffic spikes without you rearchitecting anything.

Recall is strong in the 95-99% range for ANN benchmarks using HNSW indexes. However, under extremely high throughput (millions of queries per day across billions of vectors), the cost profile becomes less predictable than a self-hosted alternative.

The Vendor Lock-In Problem

This is the most legitimate critique of Pinecone. Because it is a closed-source managed service, you have no visibility into the underlying infrastructure and no ability to migrate to another database without a data export and reimport process. For companies in regulated industries or those building core IP around their retrieval layer, this is a real risk.

Cost Model

Serverless pricing is usage-based: you pay per thousand queries. At low volume (under 100K queries/month), this is extremely cost-effective. At high volume, the per-query cost compounds. For reference, a production RAG system with 10M daily queries will cost several thousand dollars per month on Pinecone Serverless.

The hidden cost is egress — moving large datasets out of Pinecone is not free, and if you need to rebuild your index or migrate, that egress bill can be significant.

When to Choose Pinecone

You are a small-to-medium team (2-10 engineers) building a product where time-to-market matters more than infrastructure flexibility. You have no dedicated Platform Engineering team, and you want to ship the product without managing a distributed database. You are comfortable with the vendor relationship.

Milvus

What It Is

Milvus is an open-source vector database built for scale. Originally developed by Zilliz, it is the most powerful option for teams that need to store and query billions of vectors across distributed infrastructure. It is a CNCF graduated project, which means it has broad enterprise adoption and a strong ecosystem of tooling around it.

Performance Characteristics

Milvus is the performance leader at scale. Benchmarks show that Milvus handles billion-scale vector datasets with p99 latencies under 100ms on properly provisioned hardware — better than Pinecone at equivalent scale, and with more predictable performance because you control the hardware.

The key architectural difference is segmented storage and distributed query execution. Milvus shards your data across multiple query nodes, which means you can add capacity horizontally without reindexing. For use cases where your embedding dataset grows by tens of millions of vectors per day, this is the only viable option among the three.

The Operational Reality

Milvus is not a database you operate casually. The minimum viable production deployment on Kubernetes requires: etcd for coordination, Pulsar or Kafka for log streaming, MinIO or S3 for object storage, and a Milvus cluster with query nodes, data nodes, and index nodes. Each component needs monitoring, alerting, and capacity planning.

The milvus-operator project has improved the story significantly — you can now deploy Milvus on Kubernetes with a single YAML manifest and have the operator manage failover. But you still need a team that understands Kubernetes, resource allocation, and storage classes. This is not a project for a two-person startup. For teams that have already standardized on a Kubernetes-based AI platform and want to map vector-store observability onto the same Prometheus + Grafana pipeline that monitors the rest of the inference stack, the AI model monitoring vs APM comparison is a useful companion read — it walks through the specific metrics that vector-store monitoring needs (recall distribution, p95 query latency by tenant, hybrid-search BM25 vs vector ratio) that a generic APM stack will not surface out of the box.

When to Choose Milvus

You have a Platform Engineering team of 3+ engineers with Kubernetes expertise. Your vector dataset is larger than 100M embeddings, or you expect it to reach that scale within 12 months. You need fine-grained control over hardware utilization and query routing. You are building a product where the vector database is core to your competitive advantage and you cannot afford vendor lock-in.

Weaviate

What It Is

Weaviate is an open-source vector database with a developer-first philosophy. It runs as a single binary (for local development) or scales to a distributed cluster, and its standout feature is native hybrid search — BM25 keyword matching combined with vector similarity in a single query, without requiring a separate Elasticsearch cluster.

Developer Experience

Weaviate is the most pleasant database to integrate with. The client libraries (Python, TypeScript/JavaScript, Go) are well-designed and stable. The REST API is intuitive. And Weaviate's module system — which includes vectorizers like OpenAI's text-embedding-3 and Cohere built in — means you can go from zero to a working RAG pipeline in under an hour.

The console and Weaviate Cloud Services (WCS) offer a genuinely good managed experience. You can spin up a sandbox cluster in minutes, connect it to your application, and iterate without any infrastructure overhead. For prototyping and MVPs, this is the fastest path.

Hybrid Search: Weaviate's Killer Feature

Native hybrid search is the reason many teams choose Weaviate over Pinecone. In practice, RAG retrieval has two failure modes: semantic mismatch (you retrieve conceptually similar but semantically wrong chunks) and keyword mismatch (you need a specific term to appear in the retrieved chunks, but vector similarity misses it). Hybrid search addresses both simultaneously. The downstream side of this — how many chunks you actually pull, how they are ordered, and how much context budget the model has to use them — is a separate discipline covered in the context window optimization guide; the chunking and budget decisions there compound with the retrieval-precision decision you make here.

The implementation uses a Reciprocal Rank Fusion (RRF) algorithm to combine BM25 and vector scores, then returns results that are both semantically relevant and keyword-matched. For production RAG systems where precision on technical queries matters (legal documents, API references, medical literature), this is a meaningful accuracy improvement. Vector similarity is the floor, not the ceiling — production RAG stacks layer BM25, cross-encoder rerank, and rule-based filters on top of the vector query, and the multi-dimensional AI retrieval guide walks through the 2026 stack and the three anti-patterns that show up when teams stop at vector-only retrieval.

When to Choose Weaviate

You are building a RAG application where retrieval precision on technical content is critical and you need hybrid search without the operational overhead of running Elasticsearch alongside Milvus. You value developer experience and are willing to invest in a self-hosted or WCS-managed deployment. You do not have petabyte-scale requirements today but want the ability to scale without switching databases. If you are provisioning the underlying compute — picking the GPU or custom-silicon accelerator for your vector index nodes — the custom AI silicon comparison 2026 guide covers how vector-database query throughput maps onto the accelerator choice (HNSW traversal is memory-bandwidth-bound on small indexes and compute-bound on large ones, which inverts the accelerator pick). For the deployment path itself, the Terraform vs Pulumi for AI infrastructure comparison walks through the IaC trade-offs for spinning up a Weaviate cluster with the right resource profiles, replica counts, and module allowlists — both Terraform and Pulumi have native Weaviate providers, but the operational posture differs meaningfully once you add the vectorization sidecar and the backup backend.

What's New in Weaviate 1.38.6

Weaviate 1.38.6, released 2026-07-21 as the sixth patch on the 1.38 line, is a focused async-replication-hashtree-perf + lsmkv-inverted-encode-pipeline + REST-search-endpoint drop and the new recommended production pin for 1.38.x. The release body lists 35+ PRs — no breaking changes, no new features — but the LSMKV reusable encode pipeline and the REST search response envelope are the two headline wins any team running inverted-index compaction or feeding search responses straight into a RAG pipeline should treat as must-have. If you are on 1.38.5, this is a drop-in upgrade; if you are on 1.37.x, treat 1.37.12 as your conservative pin and read 1.38.6 as the line where the 1.38 line consolidates the post-1.38.5 LSMKV perf work. The headline changes:

• How does the LSMKV inverted-compaction encode pipeline get rebuilt for allocation reuse? (#12160, #12161, #12149, #12150, #12151, #12154, #12163, #12233) — The biggest single cluster of perf PRs in 1.38.6 by production impact. Until 1.38.6, the inverted-compaction path allocated encode buffers per compaction node, which on a busy cluster with frequent compactions meant sustained allocation pressure and CPU on the compactor. 1.38.6 wires the inverted compaction through a single reusable encode pipeline (reusable decode helpers + reusable decode buffers across the inverted cursor + reuse of the propLengthsView across compaction nodes + an encode-append arena primitive). The encode-pipeline work is paired with EncodeInto for BlockEntry and BlockData, which avoids intermediate copies. On a large index with sustained query load and compaction, these compound into a measurable reduction in compaction-time CPU and per-compaction allocation count — the same shape of perf win the BM25 WAND-loop sweep produced in 1.38.3, but applied to the storage layer. For teams running Weaviate with hfresh or PQ-compressed indexes (the patterns that make the storage layer the bottleneck on large tenants), 1.38.6 is the line where the compactor stops being the biggest allocator on the cluster.
• How does the REST search endpoint gain a structured response envelope? (#12133, #12077, #12227) — A small but real ergonomics + extensibility change on the REST search API. Until 1.38.6, REST search responses were a flat object with named properties, references, and metadata all untyped at the top level — which meant a RAG pipeline that wanted to extract references or metadata had to know the schema ahead of time. 1.38.6 introduces a typed envelope {id, properties, references, metadata} and a new POST /v1/search/{collection}/near-text endpoint, plus a camelCase payload + nested reserved rerank object. For teams whose RAG pipeline reads REST search responses directly (a less common but real production pattern for callers that prefer HTTP to the gRPC client), 1.38.6 is the line where the response is parseable as typed structure rather than as flat-keyed untyped blob — the same shape of ergonomics win the JSON-schema-on-REST work in the OpenTelemetry ecosystem produced for collector configurations. If you operate Weaviate as part of a multi-tenant RAG platform (the pattern the production-ready 1.38.0 Namespaces Preview started), the envelope is also the path forward for shipping typed multi-tenant responses without leaking tenant metadata into the top-level object.
• async-replication: hashbeat FSM target gate is allocation-free (#12222) — A perf PR on the async-replication hashbeat path. Until 1.38.6, the hashbeat FSM target gate allocated per tick, which on a busy HA cluster added allocation pressure on the hashbeat thread. 1.38.6 makes the gate allocation-free, which on a large multi-tenant deployment measurably cuts the hashbeat allocation rate.
• async-replication: fix ABBA deadlock between updateReplicationConfig and lazy shard load (#12238) — A real correctness fix on the async-replication + lazy-shard interaction. Until 1.38.6, a concurrent updateReplicationConfig and lazy-shard-load could deadlock the RAFT FSM. 1.38.6 corrects the lock ordering. For teams running Weaviate with both async replication and lazy shard loading enabled (the recommended pattern for large multi-tenant deployments), 1.38.6 is the line where the RAFT FSM no longer wedges under that specific combination.
• async-replication: namespace suspend RAFT states (#12239) — A correctness + ops improvement on the async-replication RAFT path. Until 1.38.6, namespace suspend could leave RAFT states in an intermediate configuration that triggered spurious re-elections. 1.38.6 suspends the RAFT states cleanly. The kind of fix that shows up as fewer spurious leader-elections during namespace-suspend operations.
• memberlist: retry on join with deadline (#12241) — A reliability fix on the memberlist join path. Until 1.38.6, a transient join failure could leave the node permanently out of the memberlist. 1.38.6 retries the join against a deadline, which on a flaky network means a node rejoins rather than getting stuck.
• memberlist: don't fail startup when a single node can't join (self-heal) (#12243) — A reliability fix paired with #12241. Until 1.38.6, a single-node join failure at startup would fail the whole memberlist bootstrap, which on a degraded network could prevent the cluster from forming at all. 1.38.6 self-heals the single-node failure so the cluster can form and the node rejoins once the network recovers. Pairs with the broader Kubernetes-cluster-formation story the Kubernetes cost optimization guide covers from a different angle.
• async-replication: fold ≤cutoff changes into async-checkpoint bounded hashtree (#12128) — A correctness fix on the async-replication hashtree path. Until 1.38.6, ≤cutoff changes were folded into the hashtree in a way that could let stale entries persist past the cutoff. 1.38.6 folds them into the bounded hashtree properly. A subtle but real correctness fix on the bounded hashtree's behavior at the cutoff boundary.
• Don't load lazy shards on property add (#12184) + Don't load lazy shards on backup restore (#12186) — Two lazy-shard correctness fixes. Until 1.38.6, adding a property or restoring from backup would force-load all lazy shards on the affected tenant, which on a tenant with many lazy shards could stall the operation. 1.38.6 keeps the lazy shards lazy on both paths. The kind of fix that shows up as a meaningful latency improvement on tenant operations against a large multi-tenant deployment. For teams running Weaviate behind a backup-restore cadence (the workflow the backup and restore playbook for vector databases walks through), 1.38.6 is the line where the post-restore operation no longer triggers a tenant-wide shard load.
• reindex: concurrent writes during migration converge into the new bucket (#11985) + fail/retry reindex task on OnTaskCompleted schema-flip failure (#11986) + mirror co-located props on batch-ref and delta writes (#12210) — Three reindex correctness fixes. Until 1.38.6, concurrent writes during a reindex migration could end up in the old bucket rather than the new one, the OnTaskCompleted schema-flip could fail without retry, and batch-ref + delta writes on co-located properties were not mirrored. 1.38.6 corrects all three. For teams running Weaviate with the 1.38.x schema-evolution workflow, 1.38.6 is the line where the migration stops silently dropping concurrent writes. If you operate Weaviate as part of a supply-chain-managed stack where reindex operations are routine, this is the fix that makes the migration predictable.

No breaking changes. No new features. This is the post-1.38.5 LSMKV-perf + async-replication-consolidation release — same posture as 1.37.12 / 1.38.5 on their respective lines, but applied to 1.38.6 with the reusable encode pipeline and the REST search envelope as the headline correctness + perf wins. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.6, or pin your Helm chart to 1.38.6. If you are on 1.38.5, this is a drop-in upgrade and the recommended pin; if you are on 1.38.0–1.38.4, treat 1.38.6 as the consolidation target. If you are on the 1.37 line, 1.37.12 remains the conservative pin and you can plan the 1.38 move separately. For teams that have been putting off the 1.38 move because the early 1.38 patches felt thin, 1.38.6 is the line where the cumulative stability + perf work crosses the production-ready threshold: LSMKV reusable encode pipeline, async-replication allocation-free hashbeat, REST search envelope, lazy-shard preserved on property add and backup restore, reindex correctness, and the memberlist self-heal all land together.

What's New in Weaviate 1.38.5

Weaviate 1.38.5, released 2026-07-16 as the fifth patch on the 1.38 line, is a focused stability + lsmkv-perf + hfresh-correctness drop and the new recommended production pin for 1.38.x. The release body lists 30+ PRs — no breaking changes, no new features — but the batch-vectorization deadlock fix and the hfresh LSM lock fix are the two headline correctness changes that any team running multi-tenant ingest or hot-tenant HFresh workloads should treat as must-have. If you are on 1.38.4, this is a drop-in upgrade; if you are on 1.37.x, treat 1.37.12 as your conservative pin and read 1.38.5 as the line where the 1.38 line consolidates the post-1.38.4 stability + perf work. The headline changes:

• How does the batch vectorization deadlock get fixed? (#12070) — A real concurrency-bug fix on the batch vectorization path. Until 1.38.5, a batch import could deadlock under specific contention patterns between the batch worker pool and the per-object vectorization lock. On a tenant ingest spike (the common production trigger — a customer uploads a large backup, or a nightly batch job kicks off), the deadlock surfaces as a hung import worker that does not show up in the standard error dashboard. 1.38.5 corrects the lock ordering so the batch vectorization path completes deterministically. For teams running Weaviate as the vector store behind a backup-restore cadence (the workflow the backup and restore playbook for vector databases walks through), 1.38.5 is the line where the post-restore import no longer hangs on the first batch.
• hfresh: never hold version-map locks across LSM operations (#12119) — A deadlock-elimination fix on the HFresh vector index. Until 1.38.5, the HFresh version-map lock could be held across an LSM operation, which on a busy shard with concurrent reads could deadlock the entire tenant. 1.38.5 scopes the version-map lock to the in-memory read path so it never spans an LSM call. For teams running HFresh in production on a hot tenant (the pattern 1.38.0 made GA), 1.38.5 is the line where the multi-tenant deadlock surface on the HFresh hot path closes.
• HNSW: clear tombstone metric on graph reset (#12131) — A correctness fix on the HNSW rebuild path. Until 1.38.5, resetting the HNSW graph could leave the tombstone metric stale, which on a subsequent read path produced a misleading "this index has tombstones" signal that affected query optimization decisions. 1.38.5 clears the tombstone metric on reset so the rebuild starts from a clean state.
• LSM perf sweep (read-buffer reuse + lock-free tombstones) — #12142 reuse read buffer in objectsByDocID + #12143 reuse read buffer in docID resolution loops + #12051 cache immutable memtable tombstone snapshot for queries + #12074 lock-free tombstone reads + write-side lock split — Four PRs that together cut allocation pressure and lock contention on the LSM read path. The read-buffer reuse PRs avoid re-allocating per-query buffers in the hot docID-resolution loop; the lock-free tombstone PR avoids taking the read lock on the tombstone check. On a large index under sustained query load, these compound into a measurable p99 latency improvement on the inverted-index read path.
• LSM: sort WALs before recovery so newest stays active memtable (#12138) — A recovery-correctness fix. Until 1.38.5, on a crash with multiple unsealed WALs, the recovery path could pick an older WAL as the active memtable, which silently discarded newer writes. 1.38.5 sorts WALs by timestamp before recovery so the newest is the active memtable. A subtle but real data-integrity fix on the crash-recovery path.
• flat: fix vectors invisible to flat cached search after restart with unflushed data (#12132) — A correctness fix on the flat-index cached-search path. Until 1.38.5, vectors that were inserted but not yet flushed to disk could be invisible to a cached flat search after a node restart (the cache was populated before the unflushed vectors were visible). 1.38.5 ensures the flat cached search respects unflushed writes. For teams using flat indexes as a fast-path for small collections, 1.38.5 is the line where the post-restart query result matches the pre-restart result.
• sroar: thread per-query budget into merge fan-out (#12076) — A concurrency-budget fix on the sroar bitmap merge path. Until 1.38.5, sroar merge fan-out was unbounded, which on a high-cardinality filter could spawn an unbounded number of merge goroutines and starve the rest of the query. 1.38.5 threads the per-query budget into the fan-out so it respects the same concurrency cap as the rest of the query. Predictable query latency under filter load.
• usage: open dimensions bucket once per shard with sequential-access hint (#12106) — A perf + concurrency fix on the usage-reporting path. Until 1.38.5, the dimensions bucket was re-opened on every report, which added unnecessary IO and lock contention on a busy shard. 1.38.5 opens the bucket once per shard with a sequential-access hint. Cuts IO on the usage-report path and reduces report-cycle lock contention.
• CI: switch acceptance / integration / module tests to ubicloud-standard-4 (#12148, #12153) — Test infrastructure work that does not change product behavior but signals a faster upstream CI cadence on the 1.38 line. Worth noting because teams that pull the Weaviate source for vendor-internal testing will see the runner change reflected in their CI mirror.

No breaking changes. No new features. This is the post-1.38.4 stability + perf consolidation release — same posture as 1.37.12 on the 1.37 line, but applied to the 1.38 line with the batch-vectorization deadlock fix, the hfresh LSM lock fix, and the LSM read-buffer reuse sweep as the headline correctness + perf wins. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.5, or pin your Helm chart to 1.38.5. If you are on 1.38.4, this is a drop-in upgrade and the recommended pin; if you are on 1.38.0–1.38.3, treat 1.38.5 as the consolidation target. If you are on the 1.37 line, 1.37.12 remains the conservative pin and you can plan the 1.38 move separately. For teams that have been putting off the 1.38 move because the early 1.38 patches felt thin, 1.38.5 is the line where the cumulative stability + perf work crosses the production-ready threshold: batch-vectorization deadlock closed, hfresh LSM lock closed, LSM read-path perf consolidated, and the async-replication hashtree perf work from 1.38.4 lands as the foundation underneath.

What's New in Weaviate 1.38.4

Weaviate 1.38.4, released 2026-07-15 as the fourth patch on the 1.38 line, is a focused async-replication hashtree-perf + BM25-block-max-WAND drop — the line where the async-replication hot path stops being the biggest allocator on a busy HA cluster. The release body lists 10 PRs — no breaking changes, no new features — and the digest-mode hashtree cursor replacement is the single biggest production-impact PR. If you are on 1.38.3, this is a drop-in upgrade; if you are on 1.37.x, treat 1.37.12 as your conservative pin. The headline changes:

• async-replication: digest-mode cursor replaces full value copies in hash-tree scans (#12121) — The biggest single PR in 1.38.4 by production impact. Until 1.38.4, the async-replication hash-tree scan path copied full object values into each hashtree node it built, which on a busy HA cluster with high async-replication throughput meant both allocation pressure and IO amplification on the replication thread. 1.38.4 replaces the full-value-copy cursor with a digest-mode cursor — the hashtree node stores a digest, and the actual value is fetched only when needed for conflict resolution. For teams running Weaviate with async replication on a busy HA cluster (the pattern the production-ready 1.38.0 replica movement assumes), 1.38.4 is the line where the replication thread allocation rate and IO drop measurably on the hash-tree scan path.
• async-replication: cut digest-scan allocations & IO, reduce default scheduler workers (#12126) — A complementary perf PR to #12121. The default scheduler-workers reduction is the lever that lets the digest-mode path scale on smaller clusters without over-subscribing the goroutine pool. Together with #12121, this is the perf pass that makes async-replication hashtree scans cheap on a busy HA cluster.
• BM25: tiered merged filter for block-max WAND (#12047) — A perf PR on the BM25 block-max WAND path. The tiered-merged filter lets the WAND scoring loop skip blocks that the merged filter has already disqualified, which on a hybrid query with a tight keyword filter cuts a meaningful amount of scoring work. For teams running Weaviate's hybrid search at scale (the pattern that combines vector + BM25 + filter), 1.38.4 is the line where the BM25 block-max WAND hot path gets a measurable p99 latency improvement on filtered queries.
• async-replication: resolve replicas locally, never implicitly activate a tenant (#12113) — A correctness fix on the async-replication read path. Until 1.38.4, a read request on a non-local replica could implicitly trigger a tenant activation on the local node (an expensive cold-start path that should only happen on a write). 1.38.4 ensures the read path resolves replicas locally without triggering the activation. A correctness + perf fix that closes a real footgun on multi-region deployments.
• async-replication: goroutine leak on tenant shutdown — settle Done()s owed by queued scheduler batches (#12127) — A goroutine-leak fix. Until 1.38.4, a queued async-replication scheduler batch that ran after tenant shutdown would never settle its Done() channels, which leaked a goroutine per leaked batch. On a busy cluster with frequent tenant turnover, the leak accumulated. 1.38.4 settles the Done()s on shutdown. A subtle but real memory-leak fix on the async-replication scheduler.
• async-replication: overwrite read-repair must not resurrect unloaded shards (#12129) — A correctness fix on the read-repair path. Until 1.38.4, an overwrite read-repair could trigger a load of an unloaded shard (the read-repair logic assumed the shard was loaded, but under specific timing it could race with a tenant deactivation). 1.38.4 guards against the resurrection. The same fix also drops a redundant REST retry that contributed to the surface. A real correctness fix on the multi-tenant async-replication path.
• async-replication: init-scan hashtree double-count and tombstone resurrection (#12130) — A correctness fix on the async-replication init-scan path. The init-scan could double-count hashes (which would inflate the hashtree) and could resurrect tombstones (which would surface stale deletes). 1.38.4 corrects both. A real data-integrity fix on the init-scan path.
• usage: serialize unloaded dimensions bucket access across concurrent reports (#12112) — A concurrency fix on the usage-reporting path. Until 1.38.4, concurrent reports could race on the unloaded-dimensions-bucket access, which produced intermittent count spikes that showed up on dashboards as phantom usage. 1.38.4 serializes the access. A small but real observability-correctness fix.
• objects: return named vectors for remote shards in objects list with include=vector (#12104) — A correctness fix on the objects-list API. Until 1.38.4, a request for objects with include=vector on a multi-tenant collection would silently drop named vectors for remote shards. 1.38.4 returns them. For teams whose RAG pipeline reads named vectors directly from the objects-list endpoint (a less common but real production pattern), 1.38.4 is the line where the remote-shard case matches the local-shard case.
• raft: warn when a schema apply stalls the FSM loop (#12124) — An observability improvement. The FSM (finite-state machine) loop on the raft consensus layer is the hot path for schema applies; until 1.38.4, a stalled FSM loop (e.g. a long-running apply that blocks subsequent applies) was invisible to the operator. 1.38.4 adds a warning when the FSM loop stalls. The kind of fix that shows up as a faster incident-triage signal on schema-apply-related incidents.

No breaking changes. No new features. The release posture is the same as 1.37.11 on the 1.37 line — pure stability + perf. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.4, or pin your Helm chart to 1.38.4. If you are on 1.38.3, this is a drop-in upgrade; if you are on 1.38.0–1.38.2, treat 1.38.4 as the consolidation target before moving to 1.38.5. If you are on the 1.37 line, 1.37.12 remains the conservative pin and you can plan the 1.38 move separately. The async-replication hashtree digest-mode work (PRs #12121 + #12126) is the headline reason to move: on a busy HA cluster with high async-replication throughput, 1.38.4 measurably cuts both allocation pressure and IO on the replication thread. The BM25 tiered-merged filter (#12047) is a secondary win that shows up on filtered hybrid queries.

What's New in Weaviate 1.38.3

Weaviate 1.38.3, released 2026-07-10 as the third patch on the 1.38 line and the new recommended production pin for 1.38.x, is a focused stability + BM25-performance + async-replication-raw-bytes drop. The release body lists 30+ PRs — no breaking changes, no new features — but the perf + replication work alone makes this a meaningful upgrade over 1.38.2. If you are on 1.38.2, this is a drop-in upgrade; if you are on 1.37.x, treat 1.37.12 as your conservative pin and read 1.38.3 as the line where the 1.38 line consolidates the post-1.38.2 stability work. The headline changes:

• Async replication: propagate raw on-disk object bytes (#11853) — The biggest single PR in 1.38.3 by production impact. Until 1.38.3, the async-replication path was re-serializing object bytes on the replication side rather than propagating the raw on-disk bytes. On a busy HA cluster that meant bandwidth amplification and extra CPU on the replication thread. 1.38.3 propagates the raw on-disk bytes through the replication path. For teams running Weaviate with async_replication_enabled: true (the recommended pattern for HA deployments with the production-ready 1.38.0 replica movement), this is the release where replication bandwidth and replication-side CPU both drop — measurable on a cluster with high write throughput.
• BM25 perf sweep (six PRs) — #11774 defer tombstone checks from advance-time to scoring + #11775 tighten block-entry scanning in the WAND loop + #11776 round-6 query-setup path optimization + #11777 round-7 matched-branch sort elision + #11915 gate DoBlockMaxWand prune-branch repair on needFullSort + #11771 lock-free atomic segment refcount — Six PRs that together produce a measurable BM25 speedup. The defer-tombstone change moves a hot-path check out of the advance-time path (where it ran for every block) and into the scoring path (where it only runs for blocks that are actually selected), which is a meaningful win on a large inverted index. The match-branch-sort elision and the prune-branch-repair gate cut the per-query work that was being done on branches that did not survive the WAND threshold. For teams running Weaviate's native hybrid search (the killer feature that makes Weaviate the developer-experience choice for RAG), the BM25 perf work compounds: p99 hybrid-query latency drops noticeably on large indexes, and the BM25 hot path stops being the slowest part of the query. The same shape of perf win shows up on the HNSW side when you pair Weaviate with a vector-database backup cadence (the pattern the backup and restore guide for vector databases covers) — a faster BM25 hot path means you can keep tighter restore-time RPS budgets without breaking query SLAs.
• Replica movement: hard-link snapshots to avoid compaction halting (#11226) + fix replica-movement restore crashloop and chained-move data loss (#11895) — Two PRs that together harden the production-ready 1.38.0 replica-movement surface. The hard-link-snapshot path means a replica movement no longer halts compaction on the source shard (previously the snapshot logic was incompatible with in-flight compaction, and the move would either stall or trigger a compaction pause that the operator could see on the dashboard). The crashloop fix closes a real data-loss risk where a failed movement chained into another movement could leave the destination shard in an inconsistent state. For teams using replica movement in production (the recommended HA pattern on 1.38.x), 1.38.3 is the release where the movement surface stops being the riskiest part of the cluster.
• Replication: rf=1 writes go through replicator when active op exists (#11867) — Until 1.38.3, a write to a shard with replication-factor 1 that had an active operation in flight could bypass the replicator (the assumption was that rf=1 meant no replication needed, but the active-op window is exactly when consistency matters most). 1.38.3 ensures the replicator is engaged when an active op exists. A correctness fix that closes a real consistency gap on single-replica shards under load.
• Backup: fix potential deadlock in big clusters (#11890) — A real correctness fix on the backup path. On large clusters with many shards, the backup coordination could deadlock under specific scheduling patterns. 1.38.3 closes the deadlock; teams running nightly backups on a multi-shard cluster should verify their backup success rate is back to 100% on 1.38.3 (some backup failures on 1.38.2 may have been the deadlock that did not surface as an obvious error). Pairs with the backup and restore playbook on the runbook side.
• HNSW: guard insert-path compression-state reads under compressActionLock (#11597) — A real correctness backport. The HNSW insert path was reading compression-state without holding the compression-action lock, which on a busy cluster with concurrent compactions could race and produce inconsistent index state. 1.38.3 (and 1.38.1 / 1.37.9, both of which carry the same fix on their respective lines) closes the race. If you have ever debugged a "this HNSW index is suddenly returning bad results after a compaction" incident, this is the fix that explains it — and 1.38.3 is the line where the race is closed on the 1.38 branch.
• RBAC: fix partial permission removal from role (#11885) + fix multi-role delete (#11904) + gate to disallow global non-operator users (#11908) + deny operator-only surface to namespaced users (#11922) — Four RBAC correctness fixes. The partial-permission-removal fix closes a bug where removing a single permission from a role could leave the role in an inconsistent state. The multi-role delete fix ensures deleting an object that has multiple roles does not leak permissions. The global-non-operator gate and the namespaced-user denial are defense-in-depth fixes that prevent privilege escalation across the namespace boundary. For teams operating Weaviate in a multi-tenant deployment (the production pattern that the 1.38.0 Namespaces Preview started), 1.38.3 is the line where the RBAC surface stops being a soft target on permission-removal paths.
• Namespaces: match colon-containing user/group IDs literally for global callers (#11868) — A correctness fix on the Namespaces Preview. Until 1.38.3, a user or group ID containing a colon (a common pattern in IdP-issued OIDC subject claims) could be misparsed as a namespace prefix, leading to a permission denial that did not match the operator's intent. 1.38.3 matches colon-containing IDs literally. If you operate Phoenix with a namespace prefix convention and your IdP issues OIDC subjects with colons (Okta, Auth0, Keycloak with custom claims), this is the fix that aligns the Namespaces Preview with your real-world user IDs.
• cgroup v2 GOMAXPROCS automaxprocs (#11918) — The Go runtime now respects cgroup v2 CPU quotas when setting GOMAXPROCS, so a container running under cgroup v2 (the default on modern Kubernetes nodes) does not over-subscribe CPU. Until 1.38.3, Go defaulted to the host CPU count rather than the cgroup quota, which on a tightly-packed Kubernetes cluster meant a single Weaviate pod could be scheduled onto a node where the cgroup quota was less than the host count — leading to throttling that the operator could not see in the standard CPU dashboards. 1.38.3 fixes this. For teams running Weaviate on Kubernetes with cgroup v2, this is the kind of fix that shows up as a noticeable reduction in throttle events. Pairs with the broader Kubernetes resource-quota story that the Kubernetes GPU scheduling guide covers.
• Test stability: TestIndex_UsageForCollection_MissingShardFiles data race fix (#11887) + wait for shard readiness after restart in TestReadRepairDeleteOnConflict (#11886) + chore: fix flakiness of TestAuthzReplicationReplicate (#11897) — Three test-stability fixes that are worth noting for teams running Weaviate against their own CI suite. The data race fix in particular uncovered a real concurrency bug in the index-usage accounting path that could surface as an intermittent count mismatch on dashboards. For teams instrumenting Weaviate with their own integration tests (the pattern the observability 2026 guide covers), the 1.38.3 fixes are worth porting into your own test suite as regression cases.

No breaking changes. No new features. This is the post-1.38.2 stability + perf consolidation release — the same posture as 1.37.12 on the 1.37 line, but applied to the 1.38 line with the BM25 perf sweep and the async-replication raw-bytes propagation as the headline perf wins. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.3, or pin your Helm chart to 1.38.3. If you are on 1.38.2, this is a drop-in upgrade and the recommended pin; if you are on 1.38.0 or 1.38.1, treat 1.38.3 as the consolidation target. If you are on the 1.37 line, 1.37.12 remains the conservative pin and you can plan the 1.38 move separately. For teams that have been putting off the 1.38 move because the early 1.38 patches felt thin, 1.38.3 is the line where the cumulative stability + perf work crosses the "production-ready" threshold: BM25 perf, async-replication bandwidth, replica-movement safety, HNSW insert-path correctness, and the RBAC defense-in-depth fixes all land together.

What's New in Weaviate 1.38.2

Weaviate 1.38.2, released 2026-06-25 as the second patch on the 1.38 line, is the largest 1.38 patch to date by PR count and the line where the post-RC stability work consolidates into a production-recommended pin. The release body lists 35+ PRs across replication, modules, BM25 performance, HNSW correctness, hfresh search, and dynamic index upgrades. The release has no breaking changes and no new flagship features — it is pure stability, security hardening, and a single new generative module (generative-deepseek). If you have been holding off on 1.38.x because the RC was too thin to pin in production, 1.38.2 is the line that closes the gap. The headline changes:

• New: generative-deepseek module (#11769) — A new generative-search module backed by DeepSeek. Until 1.38.2, teams that wanted to use DeepSeek for RAG generation had to either run a custom module or use the OpenAI-compatible adapter with an out-of-band endpoint. 1.38.2 ships a first-class generative-deepseek module with a stop setting (added in #11796). For RAG stacks that want DeepSeek on the generation side without writing a custom adapter, this is the line where the module picker surfaces it. The new module fits the same hybrid-search pattern that Weaviate is known for, so the BM25 + vector + DeepSeek-generative stack is end-to-end-native on 1.38.2.
• Security: validate X-*-BaseURL request headers to close SSRF bypass (#11683) — A real security fix. Module BaseURL request headers (used by modules that talk to external services, e.g. generative-AzureAI or generative-OpenAI) could previously be set to an arbitrary attacker-controlled URL, opening an SSRF bypass. 1.38.2 validates the headers against an allowlist. For teams that operate Weaviate as part of a broader supply-chain-managed stack (the surface the supply chain security for DevOps 2026 guide walks through), 1.38.2 is the line where Weaviate stops being a soft target on module-based SSRF. The fix is on by default — confirm your module configs still pass the new validation after the upgrade.
• Security: bump golang.org/x/net and golang.org/x/crypto libraries (#11840) — Dependency bumps that pick up upstream Go security patches. Same posture as the 1.37.x Alpine bump — worth verifying with your security team if you pin Go module versions for CVE tracking.
• Replication: optimize async replication to use efficient property unmarshalling (#11761) — A meaningful perf fix on the async-replication hot path. The previous code path unmarshalled property values one at a time; 1.38.2 batches the unmarshalling. For clusters with async replication enabled (the recommended pattern for HA deployments), this shows up as lower replication lag and lower CPU on the async-replication thread. If you have been watching async-replication lag spike during heavy ingest windows, 1.38.2 is the line that closes that gap.
• Replication: enforce tenant cap in RAFT consensus (#11752) + tenant cap rejects ingest into existing tenants (#11765) — Two PRs that together enforce the multi-tenancy cap. The first lands the cap check at the RAFT consensus layer; the second extends it to the existing-tenant path. For multi-tenant Weaviate deployments, the cap was previously advisory; 1.38.2 makes it a hard RAFT-level invariant. If you have a runaway tenant growth pattern (e.g. one bad client creating tenant IDs in a tight loop), 1.38.2 is the line where that pattern is stopped at the consensus layer rather than via out-of-band cleanup.
• HFresh: increase searchProbe default to 256 (#11793) + defer queue registration until restore completes (#11795) + fix reassign queue recovery hints (#11821) + reduce task dedup memory (#11827) — A four-PR sweep that tightens the HFresh vector index. HFresh (Harsh Freshness, the time-sensitive retrieval algorithm that 1.38.0 made GA) gets a recall bump via the searchProbe default, a startup correctness fix via the deferred-queue-registration, a recovery-hint fix, and a memory optimization. For teams using HFresh in production, the 1.38.2 release is the line that moves HFresh from "GA but rough" to "GA and stable."
• BM25 perf: faster varint decoding, WAND scoring-loop and data-structure optimizations, Tier-1 allocation cuts in the BlockMax WAND hot path (#11770, #11772, #11773) + fix BM25: record max-impact pair on memtable BlockEntry (#11780) — The headline performance story of 1.38.2. Four PRs that together produce a measurable BM25 speedup, plus a correctness fix on the memtable max-impact recording. For RAG workloads that lean on Weaviate's native hybrid search (the killer feature that makes it the developer-experience choice), the BM25 perf work compounds: queries that touch a large inverted index come back faster, and the memtable fix removes a class of ranking inconsistencies under heavy ingest. If you have been seeing p99 spikes on hybrid queries during ingest windows, 1.38.2 is the line that closes them.
• HNSW: stop dropping nodes at snapshot block boundaries (#11829) + read compression config under compressActionLock in insert validation (#11583) + make initTargetVector idempotent to prevent double-create (#11584) + serialize dynamic-index config updates against the flat-to-HNSW upgrade (#11582) + parallel-cursor prefill for unbounded uncompressed vector cache (#11838) — Five PRs that together harden the HNSW + dynamic-index path. The snapshot-block node-drop fix is a correctness issue under crash-recovery scenarios; the compression-config lock is a race fix; the initTargetVector idempotence is a startup correctness fix; the dynamic-index serialization prevents a class of mid-upgrade inconsistency; the parallel-cursor prefill is a perf fix on cold-start. The collection is the kind of patch set that shows up as a noticeable stability improvement on a long-running cluster, even though no individual PR is a "feature."
• Generative Google: add support for location setting (#11766) + text2vec-google: add location configuration (#11762) + text2vec-aws: add dimensions setting (#11764) + OpenAI: add support for endpoint setting in client (#11763) — Four small module config additions. For teams running Weaviate on Vertex AI with regional endpoints, the location setting on generative-google and text2vec-google is the change that lets you pin the module to a specific region without an env-var workaround. The text2vec-aws dimensions setting matters for teams using AWS Bedrock embeddings where the model output dimension is configurable. The OpenAI endpoint setting is a similar addition for teams that proxy OpenAI through a non-default endpoint.
• Backup: return 5xx for operational failures (#11803) — A correction to the 1.37.x 422-on-missing-backend change. 1.37.x returned 422 for "backup backend is misconfigured," but that conflated two failure modes: configuration problems (which should be 4xx) and operational problems like network timeouts or storage-backend outages (which should be 5xx). 1.38.2 returns 5xx for the operational class. For teams running a backup-and-restore workflow on top of Weaviate (the playbook the backup and restore guide for vector databases covers), this is a meaningful alerting improvement — your runbook can now distinguish "your backup backend is down" from "your backup backend is misconfigured," which is the right shape for a PagerDuty rotation.
• Backup: fix RBAC checks (#11123) — A long-standing bug where backup RBAC checks could be bypassed. 1.38.2 closes the gap; if you operate Weaviate with role-based access control and your backup surface is supposed to be admin-only, 1.38.2 makes that enforcement reliable.
• Replica movement: forbid certain schema mutations during movements (#11503) — A correctness fix for the 1.38.0 replica-movement GA. Schema mutations that would conflict with an in-flight replica movement now return an error rather than racing the movement. For teams using the production-ready replica-movement surface (the 1.38.0 GA feature), this is the patch that closes the "replica movement + schema change = inconsistent state" class of incident.
• Active-shard backup: snapshot in-place-mutated bbolt files (#11832) — A backup correctness fix. The active-shard backup path used to skip in-place-mutated bbolt files, which could result in an inconsistent backup under concurrent writes. 1.38.2 snapshots the mutated files so the backup is consistent.
• Async replication perf: reuse a single cursor across the hashbeat digest scan (#11833) — A perf fix on the async-replication hashbeat digest scan. The previous shape opened a new cursor per scan, which is wasteful on a busy cluster. The single-cursor reuse is a quiet but real perf win on large HA deployments.

No breaking changes. No new flagship features. 1.38.2 is the stability, security, and BM25-perf patch that consolidates 1.38.0-rc + 1.38.1 into a production-recommended pin. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.2, or pin your Helm chart to 1.38.2. If you are on 1.38.1, this is a drop-in upgrade; if you are on 1.38.0-rc.0, this is the line where the RC becomes a production pin. If you are on the 1.37 line, the 1.37.10 backport (released 2026-06-24) carries the same fixes plus the generative-deepseek module and the SSRF mitigation, so 1.37.10 is the conservative choice if you want one more cycle on the older line. The 1.38 line is the recommended production pin as of 1.38.2. For teams that have been putting off the 1.38 move because the RC was thin, 1.38.2 is the line that closes the gap: BM25 perf, HNSW correctness, HFresh stability, and the SSRF fix all ship together as the post-RC consolidation release.

What's New in Weaviate 1.38.1

Weaviate 1.38.1, released 2026-06-18, is a stability patch on the 1.38 line and the first post-RC release cut from main since 1.38.0-rc.0. The release body is titled "Auto-enable async replication when erf=1 and arf>1, Fix MCP hybrid search returning objects without properties" and it is a pure stability release — no breaking changes, no new features. If you are on 1.38.0-rc.0, this is a drop-in upgrade; if you are on the 1.37 line, treat 1.37.9 as your conservative production pin and read this release as a signal that the 1.38 line is moving toward a stable tag. The headline changes:

• Auto-enable async replication when erf=1 and arf>1 (#11638) — A real production safety net. If you ran a cluster with effective-replication-factor of 1 and async-replication-factor greater than 1, you had a configuration that "worked" in the sense that it started, but it was not actually doing what most operators thought it was doing. The erf=1 setting means reads are served from a single node, and arf>1 with that constraint was a silent misconfig — async replication could not be enabled because the precondition for it was not met, but the cluster did not error out. 1.38.1 auto-enables async replication when these two values are set together, so a misconfig becomes a working HA setup instead of a confusing outage. The on-call relevance: if you have ever debugged a Weaviate cluster where reads were not failing over correctly, this is the release that closes the silent-misconfig class of incident.
• Fix MCP hybrid search returning objects without properties (#11707) — A bug in the MCP (Model Context Protocol) hybrid search path that was returning objects with the properties field empty. For teams wiring Weaviate behind an MCP server and using the MCP monitoring pattern to surface the retrieval surface, the empty-properties bug meant the model saw zero context for the retrieved chunks. 1.38.1 returns the properties correctly, which makes MCP-mediated retrieval actually usable. The fix matters most for production RAG stacks where Weaviate sits behind an MCP tool and the model depends on the returned properties to do anything with the chunks.
• Validate replication factor bounds at startup (#11679) — A backport of the 1.37.9 config-validation discipline to the 1.38 line. Misconfigured replication factor values previously took the server down mid-startup or left it in a half-configured state. 1.38.1 validates the bounds at startup, so the server refuses to start with an invalid config and tells you what to change. The on-call relevance is the same as 1.37.9: it moves a class of "cluster won't come up" incidents from runtime to deploy time, where you can catch them in CI.
• Disable debug endpoints by default (#11173) — A security hardening backport from 1.37.9. The debug endpoints (introspection surfaces useful for development but should not be exposed in production) are now off by default on the 1.38 line. For teams that ran Weaviate with the debug endpoints inadvertently exposed, this is a quiet but meaningful security improvement.
• Backup module returns 422 instead of 500 on missing backend (#11666) — A backport of the 1.37.8 fix. Backup operations against a missing or misconfigured backend now return HTTP 422 (unprocessable entity) instead of HTTP 500 (internal server error). The semantic is the same: a 500 looked like an infrastructure crash when the actual problem was a misconfigured backup target. 422 is the correct semantic for "your backup backend is misconfigured," and alerting rules that key off status code can now distinguish that class of failure from a real cluster emergency.
• Race fix in usage module startup (#11684) — A backport of the 1.37.9 race fix. The usage module (the telemetry surface that tracks query patterns and ships them to the Weaviate Cloud usage endpoint) had a startup-time race that could leave the module in a half-initialized state under rapid restarts. 1.38.1 closes the race; the practical impact is fewer post-restart false alarms on usage dashboards if you are a WCS customer.
• Bucket access check is now opt-out via env vars (#11645) — The startup-time bucket access check (which validates that the cluster can talk to its object-storage backend) was previously unconditional, which broke cold-start scenarios where the bucket was reachable but slow to respond. 1.38.1 lets you disable the check via environment variables, which is the right knob for teams that want startup to proceed and the first backup attempt to surface any actual problem. The on-call relevance: cold-start incidents in air-gapped or low-bandwidth environments where the bucket check timed out, leading to a 5-minute boot delay that looked like a hang. The fix is opt-in via env var, so the safe default is unchanged.
• Security: Alpine 3.24 base image bump (#11698) — The Docker base image is bumped to Alpine 3.24 to pick up upstream security patches. Same posture as the 1.37.9 bump — worth verifying with your security team if you pin Alpine versions for CVE tracking.
• Performance: lazy loading for property lengths (#11711) — A perf backport from 1.37.9. Property-length computation is now deferred until a query actually needs it. For workloads that ingest a lot of properties but only query a few, this cuts a measurable amount of CPU off the hot path. If you are running Weaviate on tight CPU budgets (cost-sensitive cloud deployments), the difference shows up in p99 query latency on wide schemas.
• Performance: reduce goroutines spawned by cyclemanager (#11701) — A backport of a cyclemanager efficiency fix. The cyclemanager is the internal scheduler that runs periodic background work; the previous shape spawned more goroutines per cycle than the work required. On a busy cluster with many collections and shards, the per-cycle goroutine count was a measurable chunk of steady-state CPU. 1.38.1 reduces the goroutine spawn rate, which is a quiet but real perf win on large clusters.
• Perf: extension to token fetch retry budget (#11713) — The 1.37.9 token-fetch retry-budget extension is backported to 1.38.1. Transient "token fetch failed" warnings on a network blip are now non-events. Stability, not feature work — exactly what a patch release should be.

No breaking changes. No new features. This is a stability and configuration-validation patch — the same posture as 1.37.9, but applied to the 1.38 line, and with the async-replication auto-enable behavior as the production-readiness signal that the 1.38 stable tag is closer to ship. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.1, or pin your Helm chart to 1.38.1. If you are on 1.38.0-rc.0, this is a drop-in upgrade and the recommended pin; if you are on 1.37.x, treat 1.37.9 as your conservative production target and read 1.38.1 as the line that closes the silent-misconfig gap. For teams building a backup-and-restore workflow on top of Weaviate, the 422-on-missing-backend semantics fold cleanly into the vector database backup and restore playbook — alerting rules that key off status code can now distinguish "your backup backend is misconfigured" from "your cluster is on fire."

What's New in Weaviate 1.38.0

Weaviate 1.38.0, released 2026-05-27, is a release candidate for the upcoming stable v1.38. The RC ships with HFresh (now GA), Namespaces (Preview), Nested Object Filtering (Preview), production-ready Replica Movement, and Alter Schema with Reindex property (Preview):

• HFresh (GA) — Harsh Freshness algorithm is now generally available, improving recall for time-sensitive retrieval by boosting recently-added vectors without sacrificing overall accuracy.
• Namespaces (Preview) — Multi-tenant isolation at the namespace level, allowing you to partition data within a single Weaviate cluster with separate schema and vector spaces per namespace.
• Nested Object Filtering (Preview) — Filter on nested properties within objects — useful for querying structured data where you need to match on fields inside JSON blobs.
• Production-Ready Replica Movement — Dynamic rebalancing of replica shards across nodes without downtime, now production-stable for high-availability deployments.
• Alter Schema with Reindex property (Preview) — Change index configuration (e.g., HNSW parameters) on an existing collection and trigger an automatic background reindex, without recreating the collection or re-uploading data.

As an RC, this pre-release is considered feature-complete. Upgrade via Docker: docker pull semitechnologies/weaviate:1.38.0-rc.0. The stable 1.38.0 tag will follow after the RC period. Helm users can pin to 1.38.0-rc.0 or wait for the stable chart release.

To update a running Weaviate instance to 1.38.0:

docker pull semitechnologies/weaviate:1.38.0-rc.0
        # Restart the container — no schema migration required for RC upgrades

What's New in Weaviate 1.37.8

Weaviate 1.37.8, released 2026-06-11, is a backport patch on the 1.37 stable line and the recommended pin for production deployments that have not yet moved to 1.38.0. The release body lists no breaking changes and no new features — it is pure stability work, which is exactly what a patch release on a stable line should be. If you are on 1.37.x, this is a non-event upgrade; if you are on 1.38.0-rc.x, you already have the equivalent fixes plus the new features. The headline changes:

• Rate limiter in the batch-simple path — A new rate limiter was added to the batch-simple logic, addressing a long-standing tail-latency issue when a large batch import flooded the import queue. For teams running nightly bulk re-indexing jobs, this caps the burst that downstream queues see and prevents a single big job from starving smaller interactive inserts. Stability fix, but one that shows up immediately in p99 dashboards for any team running >100k objects per batch.
• Backup access check fix — Backup operations against a missing or misconfigured backend now return HTTP 422 (unprocessable entity) instead of HTTP 500 (internal server error). The 500 was misleading for runbook automation — backup jobs that failed with 500 looked like infrastructure crashes when they were actually configuration issues. 422 is the correct semantic, and alerting rules that key off status code can now distinguish "your backup backend is misconfigured" from "your cluster is on fire." Worth a one-line update to any runbook that grep'd the old behavior.
• Stable batch update timestamp (#11553) — Batch reference updates now use a single consistent update time across all referenced objects, instead of stamping each reference independently. A correctness fix that matters for any workload that depends on monotonic update ordering — incremental sync jobs, CDC pipelines, and any system that joins on "last modified" timestamps will now see deterministic ordering even under concurrent batch updates.
• Schema refactor: tokenize logic extracted to a shared usecase (#11180, reverted in #11558) — Worth noting for anyone tracking the refactor roadmap: the tokenize-logic extraction landed and was reverted the same cycle. A common pattern during a refactor — the team validates the extraction in main, then reverts when edge cases surface, and the next attempt benefits from the learning. Not user-facing, but a healthy sign that the refactor is being treated as a quality-of-life change rather than a forced migration.

No breaking changes. No new features. Pure stability. Upgrade via Docker: docker pull semitechnologies/weaviate:1.37.8, or pin your Helm chart to 1.37.8. If you are on 1.37.x, this is a drop-in patch. If you are evaluating 1.38.0, treat 1.37.8 as the conservative production line until the 1.38 stable release lands — the 1.37 line will continue to receive backports from main for security and stability fixes, just without the new HFresh / Namespaces / Replica Movement work that defines the 1.38 cycle.

What's New in Weaviate 1.37.9

Weaviate 1.37.9, released 2026-06-16, is the next backport on the stable 1.37 line and the recommended production pin for teams that have not yet moved to 1.38.0. The release body is titled "Default vector index runtime config setting validation Fix" and is primarily a correctness and configuration-validation release — the kind of patch that is easy to overlook on a marketing page but matters a lot for the on-call posture, because the underlying issues silently failed at startup or under load. The headline items:

• Default vector index runtime config validation (#11719) — The release-title change. A misconfiguration in the default_vector_index runtime setting previously crashed or silently misbehaved at server startup, depending on the code path. The fix validates the setting at startup, so a typo in your config no longer takes the cluster down — you get a clear error message and the server fails to start, which is the right failure mode for a config bug. The on-call relevance: if you have ever debugged a Weaviate deployment that "started but didn't work right," this is the release that closes that class of incident for the default_vector_index knob.
• Disable debug endpoints by default (#11173) — A real production-hardening change. The debug endpoints (introspection surfaces that are useful for development but should not be exposed in production) are now off by default. For teams that ran Weaviate with the debug endpoints inadvertently exposed, this is a quiet but meaningful security improvement — the surface area shrinks without requiring a config audit. If you have scripts that depend on a specific debug endpoint, you can re-enable it explicitly; otherwise the default behavior is now correct.
• Validate replication factor bounds at startup (#11679) — A second configuration-validation fix in the same release. Misconfigured replication factor values (e.g., asking for more replicas than the cluster can support) previously took the server down mid-startup or left it in a half-configured state. 1.37.9 validates the bounds at startup, so the server refuses to start with an invalid config and tells you what to change. The on-call relevance is the same as default_vector_index: it moves a class of "cluster won't come up" incidents from runtime to deploy time, where you can catch them in CI.
• Race fix in usage module startup (#11684) — A startup-time race in the usage module (the telemetry surface that tracks query patterns and ships them to the Weaviate Cloud usage endpoint) that could leave the module in a half-initialized state under rapid restarts. 1.37.9 closes the race; the practical impact is fewer post-restart false alarms on usage dashboards if you are a WCS customer.
• Extended token fetch retry budget (#11713) — Token-fetch operations (used by the auth layer and the usage module) now retry through a larger error window. If you have ever seen transient "token fetch failed" warnings on a network blip, this is the fix that turns them into non-events. Stability, not feature work — exactly what a patch release should be.
• Security: Alpine 3.24 base image bump (#11698) — The Docker base image is bumped to Alpine 3.24 to pick up upstream security patches. Worth verifying with your security team if you pin Alpine versions for CVE tracking; the bump is in line with the regular Alpine cadence and is not a response to a known in-the-wild exploit.
• Performance: lazy loading for property lengths (#11711) — A perf fix that defers property-length computation until a query actually needs it. For workloads that ingest a lot of properties but only query a few, this cuts a measurable amount of CPU off the hot path. If you are running Weaviate on tight CPU budgets (cost-sensitive cloud deployments), the difference shows up in p99 query latency on wide schemas.

No breaking changes. No new features. This is a stability and configuration-validation backport — the same posture as 1.37.8, but with three "server silently misbehaves" classes of incident closed off and a small set of perf and stability fixes riding along. Upgrade via Docker: docker pull semitechnologies/weaviate:1.37.9, or pin your Helm chart to 1.37.9. If you are on 1.37.x, this is a drop-in patch; if you are on 1.38.0-rc.x, you already have the equivalent fixes. The 1.37 line continues to receive backports from main for security and stability fixes independently of the 1.38 cycle, so 1.37.9 is the right conservative production pin until 1.38 stable ships. For teams building a backup-and-restore workflow on top of Weaviate — the validation in 1.37.9 is the kind of guardrail that pairs with the backup and restore playbook for vector databases when you want a cluster that fails loudly on bad config rather than silently on a query.

What's New in Weaviate 1.37.10

Weaviate 1.37.10, released 2026-06-24 as the next backport on the stable 1.37 line and a substantial stability + security + cycle-manager drop. The release body lists 30+ PRs — no breaking changes, no new flagship features — but the patch carries the same breadth of fixes that 1.38.2 folded in for the 1.38 line. If you are on 1.37.x, 1.37.10 is the recommended intermediate pin on the path to 1.37.11; if you are on 1.38.0-rc.x or 1.38.x, you already have the equivalent fixes. The headline changes:

• Optimize async replication to use efficient property unmarshalling (#11761) — Async replication was reading object properties via a generic unmarshalling path that allocated a new buffer per object. 1.37.10 switches to a typed fast-path that reuses the buffer. On a cluster with high async-replication traffic (a single-effective-replication-factor cluster in async mode is the canonical case), this is a measurable CPU and allocation drop. The 1.38.2 release on the 1.38 line carries the same fix; 1.37.10 is where it lands on the 1.37 line.
• Enforce tenant cap in RAFT (#11752) — Tenant cap enforcement moves from the data layer to the RAFT consensus layer, where it can no longer be bypassed by a client that talks directly to a node. 1.37.10 closes the bypass and is the same fix that 1.38.2 carries. For multi-tenant deployments that set a tenant cap, 1.37.10 is the release where the cap is actually enforced end-to-end.
• Feat: add generative-deepseek module (#11769) — A new generative module for DeepSeek models, mirroring the existing generative-cohere / generative-openai / generative-google module pattern. If you have been holding off on a DeepSeek-backed RAG because the module picker was missing the entry, 1.37.10 unblocks that without an env-var workaround. Pairs with the multi-LLM routing guide for teams that fan a single RAG pipeline across multiple generative backends.
• Security: validate X-*-BaseURL request headers to close SSRF bypass (#11683) — A real SSRF-bypass fix. The module BaseURL request headers (X-OpenAI-BaseURL, X-Cohere-BaseURL, etc.) were being passed through to the outbound module request without validation, which let a malicious client redirect the module call to an attacker-controlled endpoint. 1.37.10 validates the headers against an allow-list of module BaseURLs. The same fix lands in 1.38.2. For teams that operate Weaviate as part of a broader supply-chain-managed stack (the surface the supply chain security for DevOps 2026 guide walks through), 1.37.10 is the line where Weaviate stops being a SSRF pivot on the 1.37 line.
• Backup: return 5xx for operational failures (#11803) — Backup operations used to return 200 on operational failures (network blip, transient backend issue) and surface the failure as a partial backup, which then looked healthy to a monitor. 1.37.10 returns 5xx on real failures so the monitor catches them. Same fix as 1.38.2.
• hfresh: searchProbe default bumped to 256, queue + restore fixes (#11793, #11794, #11795, #11796) — hfresh (the next-gen vector index) gets a default searchProbe bump from 128 to 256 (better recall out of the box, with a small per-query cost) and a series of queue / restore fixes. For teams running hfresh on 1.37.x, 1.37.10 is the line where the default config is the right config without a manual override.
• Cycle manager: backoff-on-idle, fewer goroutines, slack notifier (#11701, #11703) — The cycle manager (the background scheduler for compactions, async replication, and similar) used to spawn a goroutine per tick and never back off when there was nothing to do. 1.37.10 reduces the goroutine count, switches to backoff-on-idle, and adds a slack notifier for release-notes flow. The practical impact: lower idle CPU on a quiet cluster, fewer goroutine-leak tickets on the on-call queue.
• Fix goroutine leak in listing all s3 backups (#11702) — The s3 backup listing path was leaking one goroutine per call. On a cluster that polls s3 backups on a schedule, the leak was a slow memory growth that took weeks to manifest. 1.37.10 closes the leak.
• RBAC: fix wrong authz check for get groups for role, fix partial permission removal from role, fix multi-role delete (#11728, #11885, #11904) — Three RBAC correctness fixes. The get-groups-for-role authz check was inverted (a non-admin role could see groups they shouldn't have). Partial permission removal left dangling references in the role binding. Multi-role delete failed silently on the second role. 1.37.10 closes all three. For teams running RBAC at scale, 1.37.10 is the release where the role-binding graph is actually consistent.
• Backup: fix backup concurrency calculation (#11733) — Backup concurrency was over-counted, which on a cluster with many collections caused backups to oversubscribe the goroutine pool and timeout. 1.37.10 corrects the calculation. The same fix lands in 1.38.2.

No breaking changes. Treat 1.37.10 as a normal minor backport on the 1.37 line — the SSRF fix, the tenant-cap enforcement, the generative-deepseek module, and the hfresh / cycle-manager / RBAC fixes are all additive or correctness. Upgrade via Docker: docker pull semitechnologies/weaviate:1.37.10, or pin your Helm chart to 1.37.10. If you are on 1.37.9, this is a drop-in patch; if you are on 1.38.0-rc.x, you already have the equivalent fixes plus the 1.38 line features. The 1.37 line continues to receive security and stability backports independently of the 1.38 cycle, so 1.37.10 is the recommended intermediate pin for teams that want to stay on the conservative line. For teams tracking the broader supply-chain posture of the 1.37 line, the supply chain security for DevOps 2026 guide walks through how the SSRF and the tenant-cap fixes fit into a defense-in-depth deployment — 1.37.10 is the line where the 1.37 branch stops being the weakest link on the security axis.

What's New in Weaviate 1.37.11

Weaviate 1.37.11, released 2026-06-30 as the latest backport on the stable 1.37 line and the recommended production pin for teams that have not yet moved to 1.38. The release body lists 22 PRs — no breaking changes, no new features — but the BM25 WAND-loop optimization pass is the biggest perf delta on the 1.37 line in months. If you are on 1.37.x, 1.37.11 supersedes 1.37.9 and 1.37.10 as the production target. Headline changes:

• perf(bm25): WAND scoring-loop and data-structure optimizations (#11773, #11774, #11775, #11776, #11777, #11915) — A six-PR optimization pass on the BM25 BlockMaxWAND scoring loop. The changes cover scoring-loop tightening, tombstone-check deferral from advance-time to scoring time, block-entry scanning tightening, round-6 query-setup path optimization, matched-branch sort elision, and gate-repair-branch on needFullSort. On a workload with high-volume BM25 hybrid search (the typical RAG pattern), the combined effect is a measurable drop in p99 query latency and a non-trivial drop in CPU per query. If you are tracking the BM25 hot path as a bottleneck on the LLM latency monitoring 2026 dashboard, 1.37.11 is the line where the BM25 path stops being the slowest part of the query.
• perf(lsmkv): lock-free atomic segment refcount (#11771) — The lsmkv segment refcount was a mutex-guarded counter, which under high-concurrency ingest was a contention point. 1.37.11 switches to a lock-free atomic. On a write-heavy workload, the lock-free path is a measurable drop in tail latency.
• perf: dense/sorted-pairs property-length representation (#11753) + direct-array compaction serialization via EncodePairs (#11754) — Two PRs that together compress the property-length representation and skip the intermediate slice in the compaction path. On a workload with wide property sets, the memory and CPU savings compound.
• feat(async-rep): propagate raw on-disk object bytes (#11853) — Async replication was re-marshalling object bytes on the receiver, which was wasted work — the sender already had the raw bytes on disk. 1.37.11 propagates the raw bytes through the replication path, so the receiver skips the re-marshalling step. On a cluster with high async-replication traffic, this is a measurable drop in receiver-side CPU and a smaller drop in network bytes (the raw bytes are typically a tighter representation than the re-marshalled form).
• fix(hnsw): guard insert-path compression-state reads under compressActionLock (#11597) — A latent read/write race on the HNSW insert path. Until 1.37.11, the insert path was reading the compression state without holding the lock, which under concurrent inserts and compression operations could read a partially-updated state and corrupt the index. 1.37.11 guards the reads under the same lock the write path uses. For teams that have ever seen an "HNSW index corruption, please rebuild" ticket on the on-call queue, 1.37.11 closes the class of corruption that causes it. The fix is the single most important correctness change in the release.
• fix: persist advanced update time when object content is unchanged (#11866) — A no-op PUT was resetting the object's update time to "now" even when the content was unchanged, which broke incremental sync workflows that key off the update time. 1.37.11 preserves the original update time on a no-op PUT. For teams that use Weaviate's update time as a CDC source, this is the line where the CDC stream is no longer polluted by no-op writes.
• Return proper error code from shard endpoints when index is not found (#11875), Fix more error codes in REST handler (#11878), Fix node handler return types (#11888) — Three PRs that tighten the error-code surface on the REST and node handlers. Until 1.37.11, several not-found and bad-input cases returned 500 or a generic error. 1.37.11 returns 404 for not-found, 400 for bad input, and the correct typed return on the node handler. For teams that have client-side retry logic that keys off the error code, 1.37.11 is the release where the client retries are correct.
• Fix partial permission removal from role, fix multi-role delete (carries forward from 1.37.10) — The 1.37.11 line also re-lands the partial-permission-removal fix and the multi-role-delete fix on the 1.37 stable line, so teams upgrading from 1.37.8 or earlier pick up all four RBAC correctness fixes in one jump.
• Fix potential deadlock in backup in big clusters (#11890) — A backup-path deadlock that triggered only on clusters above a certain size. 1.37.11 closes the deadlock. For teams running multi-node production clusters, 1.37.11 is the release where the "backup stuck at 50%" incident stops happening on big clusters.
• fix: TestIndex_UsageForCollection_MissingShardFiles data race error (#11887), test(replication): wait for shard readiness after restart in TestReadRepairDeleteOnConflict (#11886) — Two test-side fixes that closed latent data races. The first was a real race in the usage-module index path; the second was a test-infrastructure race that could mask a real regression in the read-repair-on-conflict path. Both fixes make the 1.37.11 line the right pin for production teams that run their own regression suite.

No breaking changes. No new features. Treat 1.37.11 as a normal minor backport on the 1.37 line — the BM25 WAND-loop optimization pass, the HNSW compression-state guard, the async-rep raw-bytes propagation, the lock-free lsmkv refcount, and the dense/sorted-pairs property-length representation are all additive or correctness. Upgrade via Docker: docker pull semitechnologies/weaviate:1.37.11, or pin your Helm chart to 1.37.11. If you are on 1.37.10, this is a drop-in patch; if you are on 1.38.x, you already have the equivalent fixes plus the 1.38 line features. The 1.37 line is now a stable conservative deployment — 1.37.11 is the recommended production pin for any team that is not actively moving to 1.38. For teams that are tracking the BM25 / lsmkv hot path as a bottleneck on the LLM latency monitoring 2026 dashboard, the 1.37.11 perf pass is the single biggest perf delta the 1.37 line has shipped; for teams that have ever debugged a "backup stuck" or "HNSW corruption" incident, the 1.37.11 correctness fixes are the single biggest stability delta. The 1.37 line continues to receive backports from main for security and stability fixes independently of the 1.38 cycle, but the 1.37.11 release is the high-water mark on both axes for the foreseeable future.

The Decision Framework

Choosing a vector database is not about finding the "best" one — it is about matching your constraints to the right system. Here is the decision framework that works:

Question 1: How large is your vector dataset?

If you are under 10M vectors: all three options work. The decision is about operational model and features. If you are above 100M vectors: Milvus is the only viable option without significant architectural compromises. Pinecone and Weaviate both have managed offerings that can handle larger datasets, but the cost and performance trade-offs diverge at this scale.

Question 2: Do you have dedicated Platform Engineering?

If the answer is no: Pinecone Serverless or Weaviate Cloud Services. The self-managed path for Milvus requires Kubernetes expertise that a product engineering team typically does not have bandwidth for. This is not a criticism of Platform Engineering — it is an acknowledgment that managing Milvus at production scale is a full-time job.

Question 3: Do you need native hybrid search?

If your retrieval queries involve specific terminology, technical names, product identifiers, or any scenario where keyword matching meaningfully improves result relevance: Weaviate is the clear choice. Its native BM25 + vector hybrid search is not easily replicated on Pinecone (which requires a separate elasticsearch integration) or Milvus (which needs a similar external stack).

Question 4: How mission-critical is the retrieval layer?

If your RAG pipeline is the core product and downtime directly impacts revenue: you need multi-region failover, which Pinecone Serverless provides out of the box, Weaviate WCS can provide with the right tier, and Milvus requires a significantly more complex multi-cluster setup. Factor in your RTO (Recovery Time Objective) requirements before choosing.

For teams running a unified gateway in front of the vector store — where the same proxy handles embedding model routing, retrieval retries, and per-tenant rate limiting — the inference API gateways comparison covers how Pinecone, Weaviate, and Milvus slot into LiteLLM/BentoML/Ray Serve patterns and where the gateway layer adds the most operational leverage.

Cost Comparison at Common Scales

100K vectors, 50K queries/month: Pinecone Serverless is free ( Starter tier). Weaviate Cloud Services starts around $25/month. Milvus self-hosted costs your cloud infrastructure bill (typically $50-200/month for a small production-ready cluster).

10M vectors, 5M queries/month: Pinecone Serverless runs approximately $800-1500/month. Weaviate Cloud Services at this scale is approximately $600-1200/month. Milvus self-hosted: $400-1000/month in infrastructure costs, plus engineering time.

100M+ vectors, 50M+ queries/month: Pinecone Enterprise pricing is negotiated. Weaviate Cloud Services at this scale requires custom pricing. Milvus self-hosted is the most cost-effective at scale — you are paying for compute, not a margin. The infra-line-items that show up at this scale (cross-AZ egress, NVMe volume costs, H100 footprint for hybrid workloads) are exactly the levers the carbon-aware AI inference 2026 guide walks through for the broader GPU spend underneath the retrieval layer.

What Is Coming in 2026

The vector database landscape is evolving rapidly. A few trends to track:

• DiskANN and SPTAG-style approximate nearest neighbor algorithms are being integrated into all three databases, which dramatically reduces memory requirements for billion-scale datasets without sacrificing recall.
• Multi-vector search — support for searching across multiple embedding models simultaneously — is becoming a feature of all three databases, which matters for RAG pipelines using both OpenAI and open-source embeddings.
• PostgreSQL-based vector search (pgvector, Supabase, Neon) is emerging as a competitive alternative for teams that want to consolidate their database stack. At small-to-medium scale, the operational simplicity of adding vector search to an existing Postgres instance is compelling.
• Backup and DR patterns are now first-class concerns — As production RAG stacks mature, teams are discovering that backup, point-in-time recovery, and disaster-recovery drills are not optional for vector databases any more than they are for primary OLTP stores. The vector database backup and restore guide covers how Pinecone, Weaviate, Milvus, Qdrant, and Chroma handle backup, RTO/RPO targets, and the runbook that catches a silent index corruption before it ships to users.

Conclusion

There is no universal winner. Pinecone Serverless wins on operational simplicity and time-to-market for small teams. Milvus wins on scale and cost-efficiency for large enterprises with Platform Engineering capacity. Weaviate wins on developer experience and hybrid search for RAG-heavy applications where retrieval precision is the product.

The decision framework that works: start with the team you have, not the team you hope to build. If you have two engineers and a product to ship, Pinecone is the right choice today even if you would choose Milvus at larger scale. You can migrate later. You cannot get back the engineering time spent managing infrastructure that is not your core competency.

Once you have picked the database, the next two questions are retrieval-quality depth and backup posture. The multi-dimensional AI retrieval 2026 guide covers the retrieval-quality side — hybrid search weights, re-ranking pipelines, embedding-model selection, and the eval pattern that catches a relevance regression before it lands in production. On the backup side, the backup and restore playbook for vector databases covers the snapshot, restore, and consistency-check workflow that the Weaviate 1.38.2 5xx-on-operational-failure fix changes — the playbook now distinguishes "backup backend is misconfigured" from "backup backend is down," which is the right shape for a PagerDuty rotation.