Weaviate vs Qdrant Local Docker: Memory Usage at 1M Vectors

Running a vector database locally sounds simple — until you spin up a container with 1 million embeddings and watch your dev machine’s RAM evaporate in real time.

The Memory Problem Nobody Talks About Enough

Vector search is now the backbone of RAG pipelines, semantic search, and recommendation systems. But most benchmarks focus on cloud-managed offerings, not what happens when you’re running docker run on your own hardware. That gap matters because a significant chunk of teams — from bootstrapped startups to enterprise dev environments — are doing exactly that before committing to a cloud deployment.

According to AIMuliple’s 2025 vector database adoption survey, over 60% of teams prototyping RAG pipelines start with a local Docker setup before scaling. The memory footprint at 1 million vectors is the first real stress test — and it’s where Weaviate and Qdrant diverge sharply.

Both engines have matured significantly. Weaviate v1.24+ ships with memory-mapped storage options. Qdrant v1.9+ introduced on-disk payload indexing. Both changes directly affect RAM consumption at scale. So 2025 numbers look meaningfully different from 2023 benchmarks that still dominate search results.

What this covers:

• Raw memory consumption at 1M vectors (768-dim and 1536-dim embeddings)
• How each engine handles memory pressure differently by design
• Docker-specific configuration that actually moves the needle
• Which engine fits which workload at local scale

In brief: Qdrant consistently uses 20–40% less RAM than Weaviate at 1 million vectors in local Docker deployments, primarily due to its Rust-based memory management and aggressive on-disk offloading. Weaviate compensates with richer built-in ML capabilities that justify the overhead for certain workloads.

1. At 768-dimensional vectors, Qdrant’s Docker container typically stabilizes around 3.5–4.5 GB RAM for 1M vectors; Weaviate requires 6–9 GB under comparable conditions.
2. Weaviate’s graph-based HNSW index stores more metadata in memory by default, which inflates footprint but improves multi-tenancy performance.
3. Both engines support on-disk vector storage, but Qdrant’s memmap_threshold configuration is simpler to tune for memory-constrained environments.

Why Local Docker Deployments Still Matter in 2026

The managed vector DB market exploded between 2023 and 2025. Pinecone, Weaviate Cloud, and Qdrant Cloud all saw adoption surges. But local Docker usage didn’t decline — it shifted purpose.

Teams now run local deployments for three specific scenarios: development and CI/CD testing, air-gapped enterprise environments, and cost-sensitive edge applications. According to Introl’s 2025 vector database infrastructure report, on-premises vector DB deployments grew 34% year-over-year in 2025, driven largely by data sovereignty requirements in finance and healthcare.

Weaviate started as a knowledge graph-inspired vector store (originally launched 2019) and has layered in modules for image, text, and multi-modal embeddings. Its architecture is JVM-adjacent — written in Go, but carrying design patterns that favor rich feature sets over minimal footprint.

Qdrant launched in 2021, built in Rust from day one. That choice wasn’t incidental. Rust’s ownership model gives Qdrant deterministic memory allocation without garbage collection pauses — a significant advantage when you’re managing hundreds of millions of vector dimensions in a single process.

By early 2026, Weaviate sits at v1.25.x and Qdrant at v1.11.x. Both are production-grade. Both have active communities and genuine enterprise deployments. The divergence is in philosophy: Weaviate bets on bundled capability, Qdrant bets on lean performance.

Memory Footprint at 1 Million Vectors: The Raw Numbers

With 768-dimensional vectors (standard for models like text-embedding-3-small or all-MiniLM-L6-v2), here’s what the data shows at rest in a fresh Docker container with default settings:

• Qdrant v1.9+: ~3.5–4.5 GB RSS (resident set size) for 1M vectors, HNSW index loaded
• Weaviate v1.24+: ~6–9 GB RSS for equivalent data, with default HNSW and schema loaded

At 1536 dimensions (OpenAI text-embedding-3-large or similar), both numbers roughly double. Qdrant scales more linearly. Weaviate’s overhead grows faster because its object store maintains additional metadata per vector by default.

These figures come from community benchmarks published on Elest.io’s 2025 vector DB comparison and corroborated by Qdrant’s own published benchmarks at qdrant.tech/benchmarks. Neither vendor independently audits the other’s claims, so treat these as directional, not absolute.

The gap closes considerably when you enable Weaviate’s PERSISTENCE_DATA_PATH with memory-mapped files and reduce QUERY_MAXIMUM_RESULTS. But getting Weaviate to match Qdrant’s default efficiency requires deliberate tuning. Qdrant starts lean. Weaviate starts full-featured.

Architecture Differences Driving the Gap

Weaviate maintains an in-memory object store alongside the vector index. Every object has a UUID, properties, and cross-references cached in RAM by default. At 1M vectors, that metadata layer alone can consume 1.5–2 GB — even before the HNSW graph loads.

Qdrant separates payloads from vectors more aggressively. With on_disk_payload: true in your collection config, payload data stays on disk entirely. The HNSW graph still loads into RAM, but that’s the minimum necessary for fast approximate nearest neighbor search. You’re not paying for features you didn’t ask for.

There’s a real trade-off here. Weaviate’s in-memory metadata makes multi-property filtering fast without secondary index penalties. Qdrant’s on-disk payload requires careful index configuration (payload_index) to avoid full scans on filtered queries. Neither approach is wrong — they reflect different assumptions about query patterns.

This approach can fail when Qdrant deployments skip payload indexing on filtered fields. Without explicit payload_index configuration, filtered vector search degrades to full collection scans at scale. It’s not a bug — it’s a configuration requirement that’s easy to miss.

Docker Configuration That Actually Moves the Needle

Qdrant — key settings in your config.yaml:

storage:
  memmap_threshold: 20000        # vectors above this threshold go to mmap
  on_disk_payload: true          # payloads stay on disk
  hnsw_index:
    on_disk: true                # HNSW graph on disk (slower but low RAM)

Weaviate — environment variables in docker-compose.yml:

DISK_USE_READONLY_PERCENTAGE: "80"
QUERY_MAXIMUM_RESULTS: "10000"
LIMIT_RESOURCES: "true"
GOMEMLIMIT: "6GiB"              # Go runtime memory cap (v1.23+)

GOMEMLIMIT was a significant addition. Before v1.23, Weaviate’s Go garbage collector had no hard ceiling, which caused OOM kills on constrained hosts. Setting it explicitly prevents the process from overcommitting.

Weaviate vs Qdrant at 1M Vectors in Docker

The table makes Qdrant look like the obvious winner on raw memory. That’s only true if your workload is pure vector search. Weaviate’s bundled modules eliminate a separate embedding service — which shifts the memory budget question entirely. If you’re running a text2vec-transformers module alongside Weaviate, you’re paying RAM for that container separately anyway. But you’re not writing vectorization code.

Three Real Scenarios

Scenario 1 — Constrained dev machine (16 GB laptop, local RAG prototype)

Qdrant is the clear choice. With on_disk_payload: true and memmap_threshold: 50000, you can run 1M vectors comfortably alongside a language model server. Weaviate’s default footprint will compete with your LLM inference process for the same RAM pool.

Recommendation: Start with Qdrant’s official Docker image (qdrant/qdrant:v1.11.0), mount a volume for persistence, and configure on_disk: true for both payload and HNSW graph if you’re below 32 GB RAM.

Scenario 2 — Air-gapped enterprise server (64–128 GB RAM, multi-tenant search)

Weaviate becomes competitive. Its multi-tenancy model — each tenant gets isolated HNSW shards — scales well when RAM isn’t the binding constraint. The built-in schema management and cross-references reduce integration complexity for teams without dedicated ML infrastructure engineers.

Recommendation: Set GOMEMLIMIT to 70% of available RAM, enable persistence, and use Weaviate’s multi-tenancy collection feature to isolate per-customer indexes cleanly.

Scenario 3 — CI/CD pipeline vector index tests

Qdrant wins on startup time — typically 8–12 seconds versus Weaviate’s 20–35 seconds in Docker. For ephemeral test environments that spin up and tear down collections repeatedly, that latency difference compounds across a full test suite.

Recommendation: Pin Qdrant to in-memory collection mode during CI (vectors.on_disk: false, on_disk_payload: false) for maximum speed, then switch to on-disk config for staging.

What to watch through late 2026:

• Weaviate’s roadmap mentions HNSW-on-disk as a planned feature — if it ships, the memory gap narrows significantly
• Qdrant’s sparse vector support for hybrid BM25 + dense search is maturing fast and changes the comparison for full-text use cases
• Both engines are adding scalar and product quantization, which can cut RAM by 4–8x at the cost of recall precision — worth tracking at ann-benchmarks.com

Conclusion

The Weaviate vs Qdrant local Docker memory question doesn’t have a universal winner. But it has a clear default for most teams.

Key findings:

• Qdrant uses 40–50% less RAM than Weaviate at 1M vectors with default Docker settings
• Weaviate’s overhead is largely justified by bundled ML modules — remove the modules, and the justification weakens considerably
• Both engines support on-disk storage, but Qdrant’s implementation is more mature and simpler to configure
• HNSW-on-disk, currently Qdrant-only, is the single biggest memory lever for large local deployments

In the next 6–12 months, quantization support will matter more than raw HNSW memory. Both engines are shipping int8 and binary quantization. At 1M vectors with 768 dimensions, binary quantization can theoretically drop RAM requirements to under 100 MB for the vector data alone — though HNSW graph overhead remains.

The bottom line: if memory is your primary constraint on local Docker, start with Qdrant. If you need bundled vectorizers and multi-modal support without extra service overhead, Weaviate’s RAM cost buys real capability.

Which constraint are you actually hitting — RAM or developer time? That’s the question that should drive the choice.

Data sourced from Elest.io Vector DB Comparison 2025, Introl Infrastructure Report 2025, AIMuliple Vector DB Survey 2025, and official Qdrant/Weaviate documentation and benchmarks.

References

1. Qdrant vs Weaviate vs Milvus: Which Vector Database for Your RAG Pipeline?
2. Vector Database Infrastructure | Introl Blog
3. Top Vector Database for RAG: Qdrant vs Weaviate vs Pinecone

Photo by Bernd 📷 Dittrich on Unsplash