This Vald review examines one of the more specialized entries in the vector database space: a fully open-source, Kubernetes-native distributed vector search engine built for approximate nearest neighbor (ANN) search at scale. Developed by the VDaaS team (Vald as a Service), Vald occupies a distinct niche among vector databases by requiring Kubernetes as its deployment target and using Yahoo Japan's NGT algorithm as its core search engine. For teams already running production Kubernetes clusters and needing to search across billions of high-dimensional vectors, Vald offers a compelling architecture that trades ease of initial setup for serious horizontal scalability and operational flexibility.
Overview
Vald is a highly scalable distributed fast approximate nearest neighbor dense vector search engine designed and implemented on Cloud-Native architecture. Unlike many vector databases that can run as standalone binaries or managed services, Vald is built from the ground up as a set of Kubernetes microservices. It uses NGT (Neighborhood Graph and Tree), an ANN algorithm originally developed by Yahoo Japan Research, to perform high-speed similarity searches across distributed index shards.
The system distributes vector indices across multiple agents, with each agent storing a different subset of the overall index. This distributed indexing approach allows Vald to handle billions of feature vectors by spreading the memory and compute load horizontally across your Kubernetes cluster. The architecture includes automatic vector indexing that operates asynchronously (avoiding the stop-the-world pauses common in graph-based indices), automatic index backup to object storage or persistent volumes, and index replication with automatic rebalancing when agents go down. Vald exposes a gRPC API with SDKs available for Golang, Java, Node.js, and Python.
Key Features and Architecture
Vald's architecture revolves around several core components deployed as Kubernetes pods that work together to provide a distributed vector search service.
Distributed Indexing with NGT: Vald distributes vector indices across multiple agent pods, where each agent stores a different portion of the index. The underlying NGT algorithm provides fast approximate nearest neighbor search using graph and tree structures. This distribution model means that adding more agents directly increases the total index capacity, making it straightforward to scale from millions to billions of vectors.
Asynchronous Auto-Indexing: Most graph-based ANN indices require locking during index construction, which causes stop-the-world pauses where searches cannot be served. Vald avoids this by using a distributed index graph that continues serving search requests while new vectors are being indexed. This is a significant architectural advantage for production workloads where downtime or latency spikes during indexing are unacceptable.
Index Replication and Self-Healing: Vald stores each index across multiple agents, providing built-in redundancy. When an agent pod goes down, the system automatically rebalances replicas across the remaining healthy agents. This Kubernetes-native approach to fault tolerance leverages the container orchestration platform's own health checking and scheduling capabilities.
Auto Indexing Backup: The system supports automatic backup of index data to object storage (such as S3-compatible stores) or Kubernetes persistent volumes. This enables disaster recovery and makes it possible to restore indices without re-indexing all source data from scratch.
Customizable Ingress/Egress Filtering: Vald implements its own filtering system that can be configured to fit various gRPC interfaces. This allows teams to add custom pre-processing (ingress) or post-processing (egress) logic to search and insert operations, such as feature normalization, result filtering, or data transformation.
Multi-Language SDK Support: Vald provides official client SDKs for Golang, Java, Node.js, and Python, all communicating over gRPC. This broad SDK coverage makes it accessible to teams working in different language ecosystems.
Helm Chart Deployment: Vald is deployed and configured via Helm charts, which is the standard packaging format for Kubernetes applications. Configuration options include the number of vector dimensions, replica count, resource limits, and backup schedules.
Ideal Use Cases
Large-Scale Similarity Search on Kubernetes: Vald is purpose-built for organizations that already operate production Kubernetes clusters and need to search across billions of vectors. If your infrastructure team already manages Kubernetes and you need ANN search as a platform service, Vald fits naturally into your existing operational model.
Real-Time Recommendation Systems: The asynchronous indexing architecture makes Vald well-suited for recommendation engines where new items are continuously added while search traffic must be served without interruption. The distributed agent model handles the concurrent read/write patterns these systems generate.
Image and Multimedia Search at Scale: Teams building visual similarity search, duplicate detection, or content-based retrieval systems that process hundreds of millions of image embeddings benefit from Vald's horizontal scaling. The NGT algorithm performs well on high-dimensional feature vectors common in computer vision applications.
Multi-Tenant Vector Search Platforms: Organizations building internal platforms that serve multiple teams or applications can leverage Vald's Kubernetes-native design to manage resource allocation, scaling, and isolation using familiar Kubernetes primitives like namespaces and resource quotas.
Don't use Vald if your team does not run Kubernetes in production. The Kubernetes dependency is absolute, not optional. If you need a simpler deployment model, a managed service, or want to run vector search on a single machine, look at alternatives like Qdrant, ChromaDB, or a managed Milvus offering instead.
Pricing and Licensing
Vald is fully open source under the Apache 2.0 license. There are no paid tiers, no premium features behind a paywall, and no managed service offering from the Vald team. Every feature described in this review is available to anyone who deploys the software.
The actual cost of running Vald is entirely determined by your Kubernetes infrastructure. You will need compute nodes with sufficient memory to hold vector indices (the primary cost driver), CPU for search operations, and storage for index backups. A minimal development setup might run on a small three-node cluster costing around $150-300/month on major cloud providers. Production deployments indexing billions of vectors will require substantially more resources, potentially thousands of dollars per month depending on the number of agent replicas, vector dimensions, and query throughput requirements.
Compared to managed vector database services where pricing scales with usage and storage, Vald's cost model gives you full control but shifts all operational responsibility to your team. There is no vendor to call for support, no SLA guaranteeing uptime, and no managed upgrade path. Your Kubernetes operations team owns the entire lifecycle. For organizations with mature Kubernetes platform teams, this is often preferable to per-query or per-vector pricing models that become expensive at scale.
Pros and Cons
Pros
-
True Kubernetes-native architecture: Vald is not a monolithic database bolted onto Kubernetes. It is designed as a set of cooperating microservices that leverage Kubernetes primitives for scaling, scheduling, health checking, and recovery. This means it integrates cleanly with existing Kubernetes monitoring, logging, and operational tooling.
-
Horizontal scaling to billions of vectors: The distributed indexing model where each agent stores a different index shard means scaling is straightforward. Add more agent pods and the system handles redistribution and rebalancing automatically.
-
Asynchronous indexing eliminates downtime: The distributed graph approach avoids the stop-the-world pauses that plague many ANN implementations. Production search traffic continues unaffected while new vectors are indexed.
-
No vendor lock-in or usage-based pricing: As a fully open-source Apache 2.0 project, there are no licensing surprises. You control the infrastructure and the data entirely.
-
Built-in fault tolerance: Index replication across multiple agents with automatic rebalancing when pods fail provides production-grade resilience without requiring external replication mechanisms.
-
Flexible filtering pipeline: The customizable ingress/egress filtering system allows teams to implement application-specific logic directly in the search pipeline without building separate preprocessing services.
Cons
-
Kubernetes is a hard requirement: There is no standalone binary, Docker Compose setup, or simple pip-install path. If you do not run Kubernetes, Vald is not an option. This is the single biggest adoption barrier.
-
Smaller community compared to competitors: Vald has significantly fewer community contributors, third-party integrations, and tutorial resources compared to Milvus, Qdrant, or Weaviate. Finding answers to operational questions outside official documentation is harder.
-
Operational complexity: Running a distributed vector search engine on Kubernetes requires expertise in both domains. Tuning NGT parameters, sizing agent pods, configuring backup schedules, and managing index rebalancing all demand hands-on experience that takes time to develop.
-
No managed service option: Unlike Milvus (Zilliz Cloud), Qdrant (Qdrant Cloud), or Weaviate (Weaviate Cloud), there is no hosted offering. Every aspect of operations, upgrades, monitoring, and incident response falls on your team.
Alternatives and How It Compares
Milvus is the most direct competitor in the open-source distributed vector database space. Milvus offers a richer feature set including multiple index types (IVF, HNSW, DiskANN), attribute filtering, and a managed cloud service (Zilliz Cloud). Milvus can run both on and off Kubernetes, giving it broader deployment flexibility. Choose Milvus if you want more index algorithm options or need a managed service path.
Qdrant is an open-source vector search engine written in Rust that emphasizes simplicity and performance. It runs as a single binary or in a cluster, offers a REST API alongside gRPC, and provides a managed cloud option starting with a free tier. Qdrant is a better fit for teams that want vector search without Kubernetes complexity.
Weaviate combines vector search with a knowledge graph model, offering hybrid search capabilities, built-in vectorization modules, and a managed cloud service with plans starting at $45/month. Weaviate suits teams building AI applications that need both semantic and structured search in a single system.
Pinecone is a fully managed vector database with no self-hosting option. It removes all operational overhead but introduces vendor lock-in and usage-based costs that can grow quickly at scale. Pinecone is the right choice for teams that prioritize zero operational burden over infrastructure control.
pgvector extends PostgreSQL with vector similarity search. It is the pragmatic choice for teams with existing PostgreSQL infrastructure that need basic vector search without deploying a separate database. It lacks the horizontal scaling and distributed architecture that Vald provides but requires near-zero additional operational investment.