Decision comparison
Redis Vector Search vs Weaviate
Redis Vector and Weaviate answer the same question from opposite directions. Redis adds vector search to a datastore many teams already run in production, so the marginal cost is a module and an index rather than a new system. Weaviate is built around vectors and objects, with a schema, native hybrid search and built-in embedding generation. The decision usually turns on whether you are adding retrieval to an existing stack or building the retrieval layer as its own thing.
Direct comparison. These are reviewed substitutes bought for the same job, so the differences below are the ones that decide between them.
All 2 are vector databases.
Quick Comparison
| Decision factor | Redis Vector Search | Weaviate |
|---|---|---|
| Primary role | Vector search added to a Redis you are probably already running | A database built around vectors and objects from the start |
| Data model | Vectors stored on Redis hashes or JSON documents alongside other Redis data types | Objects with properties and vectors together, with a schema and a class model |
| Hybrid search | Vector search combined with Redis query and filtering syntax | Native hybrid search blending BM25 keyword scoring with vector similarity |
| Persistence | Memory-first, with snapshotting and append-only file persistence to disk | Disk-backed store with memory used for the index |
| Operating model | Self-hosted Redis on Docker or Kubernetes, Redis Enterprise, or a managed Redis cloud on AWS, GCP or Azure | Self-hosted on Docker or Kubernetes, or Weaviate Cloud managed by the same team |
| Client libraries | Python, Node.js, Java and Go clients, with vectors on hashes or JSON documents | Python, Java, Go and JavaScript clients over REST and gRPC, with a GraphQL query API |
| Pricing model | Vector search ships inside Redis itself, which from Redis 8 is licensed under your choice of RSALv2, SSPLv1 or AGPLv3, so self-hosting is free. The distributed build is sold as Redis Cloud and Redis Enterprise Software. | Open source for self-hosting; Weaviate Cloud Free is always $0/month. Flex starts at $45/month (monthly pay-as-you-go); Premium starts at $400/month (prepaid). Flex and Premium minimums include the baseline cluster, vector dimensions, and storage; backups are additional. |
Redis Vector Search
- Primary role:
- Vector search added to a Redis you are probably already running
- Data model:
- Vectors stored on Redis hashes or JSON documents alongside other Redis data types
- Hybrid search:
- Vector search combined with Redis query and filtering syntax
- Persistence:
- Memory-first, with snapshotting and append-only file persistence to disk
- Operating model:
- Self-hosted Redis on Docker or Kubernetes, Redis Enterprise, or a managed Redis cloud on AWS, GCP or Azure
- Client libraries:
- Python, Node.js, Java and Go clients, with vectors on hashes or JSON documents
- Pricing model:
- Vector search ships inside Redis itself, which from Redis 8 is licensed under your choice of RSALv2, SSPLv1 or AGPLv3, so self-hosting is free. The distributed build is sold as Redis Cloud and Redis Enterprise Software.
Weaviate
- Primary role:
- A database built around vectors and objects from the start
- Data model:
- Objects with properties and vectors together, with a schema and a class model
- Hybrid search:
- Native hybrid search blending BM25 keyword scoring with vector similarity
- Persistence:
- Disk-backed store with memory used for the index
- Operating model:
- Self-hosted on Docker or Kubernetes, or Weaviate Cloud managed by the same team
- Client libraries:
- Python, Java, Go and JavaScript clients over REST and gRPC, with a GraphQL query API
- Pricing model:
- Open source for self-hosting; Weaviate Cloud Free is always $0/month. Flex starts at $45/month (monthly pay-as-you-go); Premium starts at $400/month (prepaid). Flex and Premium minimums include the baseline cluster, vector dimensions, and storage; backups are additional.
Public signals
Verified factual signals only. Bars appear only for like-for-like metrics with five weekly assessments for every tool; missing evidence stays explicit. These signals do not establish enterprise adoption, product quality, or total cost.
| Metric | Redis Vector Search | Weaviate |
|---|---|---|
| GitHub commits, 90d(Product adoption) | 549 | 3.6k |
| GitHub stars(Product adoption) | 6,000+ | 16,000+ |
| Search interest(Market interest) | Unavailable | 1 |
| Hacker News mentions, 90d(Community interest) | 0 | 3 |
| PyPI weekly downloads(Developer adoption) | 384.3k | 3.2M |
| Docker Hub pulls(Product adoption) | Not available | 22.1M |
| Hugging Face downloads(Product adoption) | Not available | 231 |
| Hugging Face likes(Product adoption) | Not available | 13 |
| npm weekly downloads(Developer adoption) | Not available | 264.5k |
| Product Hunt comments(Community interest) | Not available | 4 |
| Product Hunt rating(Community interest) | Not available | 4.9/5 |
| Product Hunt reviews(Community interest) | Not available | 13 |
| Product Hunt votes(Community interest) | Not available | 12 |
| Stack Overflow questions(Community interest) | Not available | 160 |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
Redis Vector Search
September 21, 2026Package vulnerabilities
PyPI · redisvl@0.27.2
0 vulnerabilities
across 1 package
Repository security score
Not available
Weaviate
September 21, 2026Package vulnerabilities
npm · weaviate-client@3.14.0 · PyPI · weaviate-client@4.23.1
0 vulnerabilities
across 2 packages
Repository security score
Not available
Interface Preview
Weaviate
Feature Comparison
| Feature | Redis Vector Search | Weaviate |
|---|---|---|
| Search | ||
| Approximate nearest-neighbour search | Full support | Full support |
| Filtered vector search | Full support | Full support |
| Native BM25 hybrid search | Partial support | Full support |
| Multi-tenancy isolation | Partial support | Full support |
| Data model | ||
| Schema for vector collections | Partial support | Full support |
| Objects with typed properties | Partial support | Full support |
| Vectors alongside non-vector workloads | Full support | Not verified |
| Built-in embedding generation | Not verified | Full support |
| Operations | ||
| Memory-resident index | Full support | Full support |
| Disk persistence | Full support | Full support |
| Replication | Full support | Full support |
| Horizontal sharding | Full support | Full support |
| Ecosystem | ||
| Existing production footprint in most stacks | Full support | Partial support |
| RAG framework integrations | Full support | Full support |
| First-party managed cloud | Full support | Full support |
| Open-source licence | Full support | Full support |
Search
Approximate nearest-neighbour search
Filtered vector search
Native BM25 hybrid search
Multi-tenancy isolation
Data model
Schema for vector collections
Objects with typed properties
Vectors alongside non-vector workloads
Built-in embedding generation
Operations
Memory-resident index
Disk persistence
Replication
Horizontal sharding
Ecosystem
Existing production footprint in most stacks
RAG framework integrations
First-party managed cloud
Open-source licence
Which to choose
Redis Vector and Weaviate answer the same question from opposite directions. Redis adds vector search to a datastore many teams already run in production, so the marginal cost is a module and an index rather than a new system. Weaviate is built around vectors and objects, with a schema, native hybrid search and built-in embedding generation. The decision usually turns on whether you are adding retrieval to an existing stack or building the retrieval layer as its own thing.
Best-fit scenarios
Choose Redis Vector Search if:
Choose Redis Vector when Redis is already in your production stack and vector search is one more thing you need it to do. Adding an index to data you are already storing avoids a second system to deploy, monitor, secure and pay for, and the operational knowledge is already in the team. It suits caching-adjacent retrieval and applications where the vectors sit close to other hot data.
Choose Weaviate if:
Choose Weaviate when retrieval is the application rather than a feature of it. The schema and object model give vectors typed properties to be filtered on, hybrid search blends BM25 with vector similarity natively, and built-in embedding generation removes a step from the pipeline. Multi-tenancy is a first-class concept, which matters when each customer needs an isolated collection.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
Do we need a dedicated vector database at all?
Not always. If you already run Redis and your corpus is modest, adding vector search there is a smaller change than introducing a new datastore, and fewer moving parts is a real advantage. A dedicated store earns its place when the retrieval layer grows its own requirements: hybrid ranking, per-tenant isolation, schema-level filtering, or a corpus large enough that it should not share memory with your cache.
How do the two handle hybrid search?
Weaviate implements hybrid search natively, combining BM25 keyword scores with vector similarity and exposing the blend as a parameter. Redis combines vector search with its own query and filtering syntax, which covers a lot of ground but is a different construction. If ranking quality on mixed keyword-and-semantic queries is central to your product, test both on your own corpus.
What about memory cost?
Redis is memory-first by design, so a large vector index has a direct and visible cost in RAM. A 1,536-dimension embedding at 32-bit precision is roughly 6 KB before index overhead, which puts 5 million documents at about 30 GB of vectors — sharing an instance with whatever sessions, caches and queues already live there. Quantisation cuts that substantially and is worth enabling early. Weaviate keeps objects on disk with the index in memory, so the RAM figure tracks the index rather than the whole corpus, at the cost of disk I/O on queries that miss cache. For a few million vectors either is manageable; past that, model the memory profile before committing.
Which is easier to operate?
Redis wins on marginal cost if you already run it: no new deployment, no new Kubernetes workload, no second backup policy, no new on-call runbook. The catch is that your retrieval index and your cache then share memory and fail together. Weaviate is a second system with its own Docker or Kubernetes deployment, its own monitoring and its own failure domain — more to run, and independent of everything else. For a small team the shared arrangement is usually right until retrieval volume makes the memory contention visible, at which point separating them becomes obviously right.
Can Weaviate generate embeddings for us?
Yes — Weaviate can call an embedding model as part of ingestion and query, so text goes in and vectors are produced inside the database. That removes a step from the pipeline and couples you to that configuration. With Redis you generate embeddings yourself and store them, which is more code and more control.