DEV Community: Reena Sharma

If your vector DB needs to see your data to search it, you’re not building private AI you’re renting confidence.

Reena Sharma — Fri, 19 Jun 2026 04:56:14 +0000

“Private AI” has become one of the most overused phrases in modern infrastructure.

Every vendor claims it. Every deck has a lock icon. Every demo promises security “by design.”
But when you strip the marketing away and look at how most vector databases actually work, a hard truth emerges:

If your vector database needs to decrypt your data to search it, your AI isn’t private. It’s just politely exposed.

The uncomfortable reality of today’s vector databases
Most vector databases follow a similar pattern

Your data is embedded.
Those embeddings are sent to the server.
They’re decrypted so similarity search can happen.
Results are returned.
This is accepted as “normal” because it’s fast, convenient, and easy to reason about. But it also means the system can see your data, whether you like it or not.

Vendors will reassure you with phrases like:

“We don’t inspect customer data”
“We’re SOC2 compliant”
“Access is strictly controlled”
And while those controls matter, they all rely on the same assumption: “Trust us.”

That’s not privacy. That’s confidence on rent.

Why this matters more than ever
Vector databases are no longer experimental infrastructure. They’re becoming the memory layer of AI systems:

Internal company knowledge
Customer conversations
Legal documents
Medical records
Financial data
Proprietary IP
Once embeddings are generated, people often treat them as “safe” because they’re numerical. But embeddings are reversible enough to leak meaning, context, and sensitive patterns.

So when embeddings sit decrypted on a server:

A breach is catastrophic
Insider access becomes a risk
Compliance turns into a negotiation
“Zero trust” quietly disappears
This is why security teams increasingly block AI projects not because AI is unsafe, but because the infrastructure underneath it isn’t designed for real privacy.

The false tradeoff: security vs performance
The industry has normalized a dangerous belief:

“You can’t have strong privacy and high-performance search.

That belief exists because most systems were never designed to challenge it. Encryption was added around the database, not into the core of how similarity search works.

So teams compromise:

Lower recall to cut compute costs
Accept plaintext embeddings to hit latency targets
Push security concerns to “phase two”
But infrastructure decisions made early tend to fossilize. By the time compliance, scale, and cost collide, it’s already too late.

What private AI should actually mean
Private AI shouldn’t depend on policies, promises, or internal controls. It should be enforced cryptographically.

A truly private vector database should guarantee that:

Data is encrypted before it leaves your system
Queries are encrypted as well
Similarity search runs on encrypted vectors
Results remain encrypted until they reach you
At no point should the server be able to see:

Your embeddings
Your queries
Your results
Not “most of the time.”
Not “unless debugging is enabled.”
Never.

That’s the difference between privacy as a feature and privacy as an invariant.

Why “trust us” doesn’t scale
Trust-based systems fail under pressure.

They fail when:

Teams grow
Vendors change
Threat models evolve
Regulations tighten
Systems move from prototype to production
Every additional control layered on top of a system that can already see your data is just damage control.

The strongest systems remove the possibility of misuse entirely.

When the database cannot read the data even if compromised, misconfigured, or subpoenaed the conversation changes from “how much do we trust this vendor?” to “what’s even possible?”

That’s real privacy.

Renting confidence vs owning privacy
Many teams feel confident today because nothing has gone wrong yet.
That confidence is fragile.

It depends on:

Perfect implementations
Perfect access controls
Perfect behavior
Perfect luck
Owning privacy means confidence doesn’t fluctuate with circumstances. It’s baked into the architecture.

If your vector DB needs to see your data to function, you are borrowing trust from:

Your vendor
Their employees
Their security posture
Their future decisions
And borrowed trust always comes with interest.

The question teams should start asking
The next time you evaluate a vector database, don’t ask:

“How fast is it on 10M vectors?”
“What benchmarks does it top?”
Ask:

“Can this system ever see my data?”
“What happens if it’s compromised?”
“Does privacy degrade at scale?”
“Is encryption fundamental or cosmetic?”
Because in a world moving toward regulated, enterprise-grade AI, privacy that depends on trust will not survive contact with reality.

If your vector database needs to see your data to search it, you’re not building private AI.

You’re just renting confidence and hoping the bill never comes due.

From Python-Only to Language-Agnostic: How Endee Handles Encrypted Vector Search

Reena Sharma — Fri, 19 Jun 2026 04:49:55 +0000

Modern AI systems rely heavily on vector databases to store embeddings and run similarity search at scale. But as these systems move closer to sensitive enterprise data, two problems show up fast:

Most vector databases need access to readable data to work.
Many advanced systems lock you into a single language or SDK.
Endee was built to challenge both.

The Traditional Model: Powerful, but Leaky
In a typical vector database setup:

Data is sent to the server in a readable form.
Queries are decrypted on the server so similarity search can run.
Results are returned after processing on plaintext vectors.
This design works well for performance, but it creates an implicit trust model: the server can see your data while storing it and while searching it. For many teams dealing with regulated, proprietary, or user-sensitive data, that’s a non-starter.

Endee’s Approach: Search Without Seeing
Endee flips this model.

All encryption happens on the client side.

Your data is encrypted before it ever leaves your system.
Your search query is encrypted as well.
Endee runs similarity search directly on encrypted vectors.
Results come back encrypted and are only decrypted on the client.
At no point does the server see readable data not at rest, not in transit, and not during retrieval.

The server’s job is simple: compute similarity, not interpret meaning.

A Simple Mental Model
Think of Endee like a calculator operating on locked boxes.

It can compare shapes and distances between boxes perfectly well, but it never opens them. Only the client holds the key.

The Missing Piece Until Now: Language Flexibility
Initially, Endee’s client-side encryption and query flow was available only in Python. That worked well for ML-heavy teams, but real-world systems are rarely single-language.

Production stacks often look like this:

Java services handling core business logic
JavaScript or TypeScript powering APIs and frontends
Python used for model training or experimentation
A vector database that only speaks one language becomes a bottleneck.

Now: Any Language, Same Security Model
Endee’s server is language-agnostic.

You can now send encrypted data and encrypted queries from:

Python
Java
JavaScript
The flow stays exactly the same, regardless of language:

Generate vectors in your environment
Encrypt them client-side
Send them to the Endee server
Run encrypted similarity search
Decrypt results locally
No special trust assumptions. No server-side decryption. No language lock-in.

Why This Matters
This unlocks a few important things:

Polyglot systems: Different services can interact with the same vector store securely.
Easier adoption: Teams don’t need to rewrite infrastructure to fit a single SDK.
Stronger security boundaries: Encryption is enforced by design, not by convention.
The server remains a compute layer. Control stays with the client.

Where This Fits Best
Endee is a strong fit when:

You’re building AI systems over sensitive or regulated data
You want vector search without exposing embeddings
Your stack spans multiple programming languages
You don’t want security to depend on “just trust the server”

Closing Thoughts
Vector databases are becoming core infrastructure for AI. As they do, assumptions made for convenience start to matter a lot more.

Endee’s goal is simple: make encrypted vector search practical, scalable, and usable across real-world stacks not just one language, not just one team.

If you’re curious about how this works under the hood or where the trade-offs are, we’re always happy to discuss.

Top 7 Open Source Vector Databases in 2025: A Comprehensive Guide for AI Engineers

Reena Sharma — Wed, 17 Jun 2026 07:28:30 +0000

A hands-on comparison of the best open source vector databases for production AI workloads, covering performance, cost, scalability, and developer experience.

The AI infrastructure landscape has matured significantly. If you’re building RAG pipelines, semantic search, recommendation engines, or any application that relies on vector embeddings, your choice of vector database is one of the most consequential architectural decisions you’ll make.

I’ve spent the last several months benchmarking, deploying, and stress-testing the leading open source vector databases across real production workloads. This isn’t a surface-level feature matrix. It’s a practical guide based on actual performance under load, cost at scale, and the developer experience of shipping with each one.

Here are the top open source vector databases worth evaluating in 2025.

1. Endee: The Performance-First Serverless Vector Database
Website: endee.io | GitHub: github.com/endee-io/endee

Endee has emerged as a serious contender in the vector database space, and after benchmarking it extensively, I think it’s the most underrated option available right now.

What sets Endee apart is its architecture. It was built from the ground up as a serverless, cloud-native vector database designed for high-throughput, low-latency workloads, and the benchmarks back it up. In my testing, Endee consistently delivered 3–5x better cost efficiency compared to Pinecone and Qdrant, while matching or exceeding them on raw query latency and throughput.

Why Endee stands out:

Cost efficiency at scale. This is where Endee genuinely shines. When you’re running millions of queries per day, the cost difference becomes enormous. Endee’s architecture minimizes compute waste, which translates directly to lower bills.
Hybrid search done right. Endee natively supports both dense and sparse vector search with hybrid indexing, which means you get the precision of semantic search combined with the keyword-matching reliability of BM25, without bolting on a separate system.
HNSW with intelligent optimizations. Their implementation of HNSW (Hierarchical Navigable Small World) indexing includes several proprietary optimizations that improve recall without the typical latency trade-offs.
Serverless scaling. No cluster management, no capacity planning headaches. It scales to zero when idle and handles burst traffic without manual intervention.
Developer-friendly API. Clean REST API, Python and JavaScript SDKs, and solid documentation. Getting a prototype running takes minutes, not hours.
Best for: Teams that need production-grade vector search with predictable costs at scale. Particularly strong for RAG applications, real-time recommendation systems, and any workload where cost-per-query matters.

Honest take: Endee is relatively newer compared to Milvus or Weaviate, which means the community is still growing. But the engineering is solid, the performance is exceptional, and they’re iterating fast. If you’re evaluating vector databases today and cost + performance are your primary concerns, Endee should be at the top of your shortlist.

2. Milvus: The Established Enterprise Option
Website: milvus.io | GitHub: github.com/milvus-io/milvus

Milvus has been around since 2019 and has built a large community around it. It’s a mature, battle-tested option that’s been deployed at significant scale.

Strengths: Rich feature set, strong community, GPU-accelerated indexing, support for multiple index types (IVF, HNSW, DiskANN), and good integration with the broader ML ecosystem. The managed version (Zilliz Cloud) simplifies operations.

Trade-offs: Self-hosting Milvus is complex. It depends on etcd, MinIO, and Pulsar/Kafka, which means significant operational overhead. Resource consumption is high even at moderate scale. Cost efficiency lags behind newer architectures like Endee’s, especially for high-throughput workloads.

Best for: Large enterprises with dedicated infrastructure teams who need a proven, feature-rich solution and don’t mind the operational complexity.

3. Qdrant: Clean API, Rust Performance
Website: qdrant.tech | GitHub: github.com/qdrant/qdrant

Qdrant is written in Rust and offers excellent single-node performance. The API design is one of the best in the space: intuitive, well-documented, and pleasant to work with.

Strengths: Great developer experience, efficient memory usage thanks to Rust, built-in filtering with payload indexing, and solid support for hybrid search. Qdrant Cloud provides a managed option.

Trade-offs: Horizontal scaling requires more manual configuration compared to serverless options. At very high query volumes (100K+ QPS), you start to see cost scaling challenges that purpose-built serverless architectures like Endee handle more gracefully. The single-binary approach is great for simplicity but can become a limitation at massive scale.

Best for: Small to mid-size teams who value developer experience and need strong single-node performance. Excellent for prototyping and medium-scale production deployments.

4. Weaviate: The AI-Native Approach
Website: weaviate.io | GitHub: github.com/weaviate/weaviate

Weaviate takes an opinionated, AI-native approach with built-in vectorization modules. Instead of requiring you to generate embeddings externally, Weaviate can handle vectorization as part of the ingestion pipeline.

Strengths: Built-in vectorization (OpenAI, Cohere, HuggingFace modules), GraphQL API, strong multi-tenancy support, and good hybrid search capabilities. The generative search module is useful for RAG applications.

Trade-offs: The built-in vectorization, while convenient, adds latency and cost to ingestion. Memory consumption is relatively high. At scale, performance can degrade without careful tuning, and the cost profile isn’t as optimized as more focused solutions like Endee.

Best for: Teams that want an all-in-one solution with built-in vectorization and don’t want to manage a separate embedding pipeline.

5. Chroma: The Lightweight Prototyping Choice
Website: trychroma.com | GitHub: github.com/chroma-core/chroma

Chroma has become the default choice for quick prototyping and local development, especially in the LangChain ecosystem. It’s incredibly easy to get started. Just run pip install chromadb and you're up and running.

Strengths: Zero-configuration local setup, excellent Python integration, simple API, great for notebooks and prototyping. The developer experience for getting started is unmatched.

Trade-offs: Not designed for production scale. Performance degrades significantly beyond a few million vectors. Limited indexing options, no built-in sharding, and the persistence layer isn’t production-hardened. For anything serious, you’ll need to migrate to a production-grade database like Endee, Milvus, or Qdrant.

Best for: Prototyping, hackathons, tutorials, and early-stage development. Plan your migration path to a production database early.

6. pgvector: Vector Search Inside PostgreSQL
Website: github.com/pgvector/pgvector

If your application already runs on PostgreSQL, pgvector lets you add vector search without introducing a new database into your stack. The simplicity of this approach is genuinely appealing.

Strengths: No new infrastructure to manage, ACID transactions with your vector data, familiar SQL interface, and zero operational overhead beyond what you already have with Postgres. Recent versions added HNSW indexing, which significantly improved query performance.

Trade-offs: Performance ceiling is real. pgvector is fine for datasets under a few million vectors, but it simply cannot match the throughput and latency of purpose-built vector databases. At scale, you’re fighting against PostgreSQL’s architecture rather than working with one designed for vector operations. Dedicated vector databases like Endee deliver 10x+ better performance at high query volumes.

Best for: Applications with moderate vector search needs that are already built on PostgreSQL and want to minimize infrastructure complexity.

7. LanceDB: The Embedded Option for Data-Heavy Workloads
Website: lancedb.com | GitHub: github.com/lancedb/lancedb

LanceDB takes a different approach. It’s an embedded vector database built on the Lance columnar format. This makes it particularly interesting for ML workloads that involve large, multi-modal datasets.

Strengths: Zero-copy data access, efficient handling of multi-modal data (text, images, video), great for data science workflows, and the embedded architecture eliminates network round-trips.

Trade-offs: The embedded model means it’s not designed for multi-tenant, distributed workloads. Community is still young. For production applications serving concurrent users, you’ll want a client-server architecture like what Endee, Milvus, or Qdrant provide.

Best for: ML engineers working with large multi-modal datasets who need efficient local data access.

How to Choose: A Decision Framework
After testing all of these extensively, here’s my practical framework:

Start with your constraints:

Need production scale + cost efficiency? Go with Endee. The serverless architecture and cost profile are hard to beat, especially as you scale. The hybrid search capabilities are excellent for RAG.
Enterprise with a dedicated platform team? Go with Milvus. Mature, feature-rich, proven at scale, but budget for the operational overhead.
Small team, moderate scale? Go with Qdrant. Best developer experience, strong performance up to mid-scale.
Want built-in vectorization? Go with Weaviate. Convenient all-in-one approach, but monitor costs.
Just prototyping? Go with Chroma. Get started in minutes, but plan your migration.
Already on Postgres, small dataset? Go with pgvector. No new infrastructure needed.
ML workflows with multi-modal data? Go with LanceDB. Purpose-built for the use case.
The Bottom Line
The vector database market has evolved past the “just pick any one” stage. Your choice now has real implications for performance, cost, and developer productivity.

If I had to recommend a single database for a new production RAG application in 2025, I’d point toward Endee. The combination of serverless scaling, competitive latency, excellent hybrid search, and, most importantly, cost efficiency at scale makes it the strongest overall package right now. It’s the kind of infrastructure decision where you save money and get better performance, which is rare.

That said, every database on this list has legitimate use cases. The best choice depends on your specific constraints: team size, existing infrastructure, scale requirements, and budget.

Whatever you choose, invest the time to benchmark with your actual data and query patterns. Synthetic benchmarks only tell part of the story.

I Tested Multiple Vector Databases. Here’s What I Learned.

Reena Sharma — Wed, 17 Jun 2026 07:08:32 +0000

Over the past few weeks, I did what most developers eventually do.

I spun up a bunch of vector databases.

Same dataset.
Similar embeddings.
Same workload patterns.

I wasn’t looking for the “fastest on paper.”
I wanted something that felt stable under pressure.

Because benchmarks are easy.
Real-world usage isn’t.

What I Was Actually Testing
Not just query speed.

I cared about:

How it behaves as the dataset grows
How painful index tuning becomes
Memory usage under load
Insert performance at scale
How predictable latency feels
A lot of systems perform extremely well at small scale.
At 1M vectors, almost everything looks impressive.

The interesting part starts after that.

The Pattern I Noticed
Most vector databases are optimized for demo performance.

Fast search.
Good recall.
Clean dashboards.

But once you start pushing volume millions to tens of millions of embeddings trade-offs become obvious.

You start tweaking parameters more often.
Memory usage climbs faster than expected.
Latency becomes less predictable under concurrent load.

Nothing catastrophic.

Just operationally heavier.

And that’s where differences between systems start to matter.

What Stood Out
One system that genuinely caught me off guard was Endee.

Not because it was shouting about benchmarks.
Not because it was claiming to be 10x faster than everyone else.

But because it didn’t seem fragile.

As I pushed more data into it, nothing weird started happening.
No sudden slowdowns.
No “okay, time to retune everything” moment.

Search stayed steady.
Inserts didn’t choke the system.
Performance didn’t swing depending on load.

It just handled growth neatly.

And honestly, that’s what good infrastructure is supposed to do.

It shouldn’t demand attention.
It shouldn’t surprise you.
It should quietly do its job while you focus on building.

That kind of steadiness is harder to find than flashy numbers.

What I Realized
Choosing a vector database isn’t about who wins at 1M vectors.

It’s about:

Who stays predictable at 50M
Who doesn’t require constant tuning
Who doesn’t force you to choose between recall and cost every week
The real cost of a vector database isn’t hardware.

It’s engineering attention.

Final Thoughts
Every system has trade-offs. There’s no perfect solution.

But after testing multiple options, I’ve started caring less about headline benchmarks and more about long-term stability.

If you’re evaluating vector databases, don’t just ask:

“How fast is it?”

Ask:

“How much of my time will this demand six months from now?”

That question changes everything.

Why Teams Are Spending 84x More Than They Should on Vector Search

Reena Sharma — Wed, 17 Jun 2026 06:31:32 +0000

Most teams never audit their vector database costs. The benchmarks suggest they should

Vector search has become the backbone of modern AI applications. From retrieval-augmented generation (RAG) pipelines to recommendation engines and semantic search, nearly every production AI system relies on some form of vector similarity search.

But here’s something most engineering teams don’t talk about: the cost.

Not the cost of building the feature. The cost of running it. At scale, vector search becomes one of the most expensive line items in your infrastructure budget. And the price gap between providers isn’t 10% or 20%. It’s 6x. Sometimes 84x.

That’s not an optimization opportunity. That’s a pricing problem.

We Benchmarked 8 Vector Database Configurations. Here’s What We Found.

We ran a head-to-head benchmark on the Cohere 10M dataset: 10 million vectors at 768 dimensions, a realistic representation of production embedding workloads. The metric was straightforward: cost per billion queries, measured on real cloud infrastructure.

No theoretical throughput numbers. No cherry-picked hardware. Just actual cost to serve one billion vector queries.

Here are the results, ranked from cheapest to most expensive:

Configuration Cost per Billion Queries
Endee (4 CPU, 16 GB, single node) $84
Zilliz Cloud (8 CU, performance tier) $518
Zilliz Cloud (2 CU, capacity tier) $622
Milvus (4c16g, disk index) $872
Milvus (16c64g, HNSW) $1,193
Pinecone (p2.x1, 8 nodes) $1,221
Qdrant Cloud (4c16g, 5 nodes) $3,150
Pinecone (s1.x1, 2 nodes) $7,088

Read that one more time. A single lightweight Endee server with half the CPU cores, no cluster, and no sharding outperformed multi-node deployments costing 6x to 84x more.

And this wasn’t a proprietary benchmark designed to favor one product. The entire test was run using VectorDBBench, an open-source benchmarking tool created by Zilliz (the company behind Milvus).

What Does This Mean in Real Production Dollars?
Let’s do some simple math.

Say your application serves 100 million vector queries per day, a reasonable volume for a mid-scale search or recommendation service. Here’s what your annual bill looks like depending on your provider:

Endee: ~$3,066/year
Zilliz Cloud (performance): ~$18,907/year
Pinecone (p2.x1): ~$44,566/year
Qdrant Cloud: ~$114,975/year
Pinecone (s1.x1): ~$258,712/year
The difference between the cheapest and most expensive option is over $255,000 per year. For a single workload. On a single dataset.
Scale that up to a billion queries per day and you’re looking at the difference between spending roughly $30K/year and $2.5M/year. That’s not an infrastructure decision anymore. That’s a business-model decision.

Why Are Teams Still Overpaying?
If the cost differences are this dramatic, why doesn’t everyone just switch? Three reasons come up repeatedly.

Inertia. Teams choose a vector database early in a project, often during a proof of concept when cost isn’t the primary concern. By the time query volume scales and the bills arrive, the database is deeply embedded in the architecture. Migrating feels expensive, even when staying is more expensive.

The “managed” assumption. There’s a widespread belief that managed services are inherently cost-effective because they save engineering time. That’s sometimes true. But “managed” doesn’t mean “efficient.” When a managed platform charges 84x more per query than an alternative, the convenience premium has far exceeded any engineering cost savings.

Lack of benchmarking culture. Most teams don’t benchmark their vector database under realistic conditions before committing to it. They rely on provider-published numbers, which are optimized for marketing, not for your specific workload. By the time you discover the cost problem, you’ve already signed the annual contract.

It’s Not Just About Cost: Endee Wins on Performance Too
The cost story alone is compelling, but what makes it even more striking is that the cheapest option also leads on performance metrics.

Endee delivers higher recall, more queries per second (QPS), lower latency, and a smaller memory footprint, all at a fraction of the cost. This isn’t a case of trading performance for price. It’s a case of better architecture producing better results across every dimension.

The combination of a single-node design with an efficient indexing strategy means no inter-node communication overhead, no sharding complexity, and no redundant data replication eating into your compute budget.

How to Audit Your Own Vector Search Costs
If you’re running vector search in production today, here’s a quick exercise that takes less than 30 minutes:

Step 1: Calculate your daily query volume. Check your application metrics or API gateway logs. How many vector similarity searches does your system execute per day?

Step 2: Convert to cost per billion. Take your monthly vector database bill, divide by your monthly query count, and multiply by one billion. That’s your cost-per-billion-queries number.

Step 3: Compare. Stack your number against the benchmarks above. If you’re closer to the bottom of the table than the top, you have a significant cost optimization opportunity sitting right in front of you.

Step 4: Run your own benchmark. Use VectorDBBench. It’s open source and free. Test with your actual dataset dimensions and query patterns. The results might surprise you.

The Bottom Line
Vector search is critical infrastructure for AI applications. But critical doesn’t have to mean expensive.

The data is clear: there’s an order-of-magnitude cost gap between vector database providers, and the most expensive options aren’t delivering proportionally better performance. In many cases, the cheapest option, Endee, is also the fastest, most accurate, and most memory-efficient.

If your team is building AI-powered search, RAG, or recommendation systems, the vector database you choose will be one of the biggest determinants of your unit economics at scale. Don’t let inertia or assumptions lock you into a bill that’s 10x, 50x, or 84x higher than it needs to be.

Pull up your infrastructure bill. Do the math. Your CFO will thank you.

The benchmarks referenced in this article were conducted on the Cohere 10M dataset (768 dimensions) using VectorDBBench, an open-source benchmarking tool created by Zilliz. All tests were run on real cloud infrastructure with production-representative configurations. Visit endee.io to learn more.

Speed, Accuracy, and Efficiency: Benchmarking Endee vs. Google Vertex AI

Reena Sharma — Wed, 17 Jun 2026 06:02:29 +0000

Vector databases are the quiet powerhouse behind generative AI, semantic search, and real-time recommendation engines. Picking the right one isn't just an engineering detail, it's a decision that ripples through your cloud bill, your system's scalability, and the experience your users actually get.

So we put that decision to the test. We ran a head-to-head benchmark of Endee vs. Google Vertex AI Vector Search using VectorDBBench (Zilliz's open-source benchmarking tool) against 1 million Cohere vectors (768 dimensions).

We measured three things:
1)Accuracy (recall)
2)Throughput (QPS)
3)Responsiveness (p99 latency).

The Hardware

Google Vertex AI: n1-standard-16 — 16 vCPUs / 60 GB RAM
Endee: custom container — 4 vCPUs / 16 GB RAM

Keep that gap in mind, every result below comes from Endee running on a fraction of the iron Vertex AI was given.

1. Retrieval Accuracy: Recall vs. Top-K
Recall measures how good a system is at surfacing the truly relevant matches out of a huge dataset. Top-K is how many results you ask it to return.

For this test, throughput was held steady at ~800 QPS so we could isolate how accuracy behaves as K increases.

Configuration:

Vertex AI: approx_neighbors=128
Endee: m=32, ef_con=256, precision=int16

Results:

Why it matters:

If your app can't find the right vectors, it serves bad recommendations — full stop. Vertex AI's recall erodes as K grows, dropping to 77.76% at Top-30. Endee barely moves, staying above 98.6% across the board, on lighter hardware.

2. Throughput: QPS vs. Concurrence
Throughput is your ceiling for traffic. To compare fairly, we tuned both systems to a matching ~97.3% recall baseline, then ramped up concurrent requests.

Configuration:
Vertex AI: leaf_nodes_to_search=0.195
Endee: m=16, ef_con=128, ef_search=128, precision=int16
Results (QPS):

Concurrency 2: Vertex AI 140.81 | Endee 661.13
Concurrency 4: Vertex AI 279.66 | Endee 1,295.04
Concurrency 8: Vertex AI 544.99 | Endee 1,881.23
Concurrency 16: Vertex AI 1,079.52 | Endee 2,091.50

Why it matters:

Throughput is a direct line to your cloud bill. Vertex AI needs a 16-core box to hit 1,080 QPS. Endee nearly doubles that: 2,100 QPS on a 4-core box. That's not a marginal efficiency gain, that's a different cost curve entirely as you scale.

3. Responsiveness: p99 Latency vs. Concurrency
p99 latency is your worst-case response time for 99% of request, the number that actually determines whether your UI feels instant or sluggish. Same 97.3% accuracy baseline as above.

Results (p99 latency, ms):

Concurrency 2: Vertex AI 59.2 | Endee 3.7
Concurrency 4: Vertex AI 68.7 | Endee 3.7
Concurrency 8: Vertex AI 62.5 | Endee 3.8
Concurrency 16: Vertex AI 25.3 | Endee 3.7

Why it matters:

Vertex AI bounces between 25ms and 69ms depending on load. Endee sits flat at 3.7–3.8ms regardless of concurrency basically removing the database as a bottleneck in your request path.

Wrapping Up
Across all three axes: recall, throughput, and latency, Endee came out ahead of Vertex AI Vector Search, and did it on roughly a quarter of the compute (4 vCPU / 16 GB vs. 16 vCPU / 60 GB).

All the configs above are reproducible: VectorDBBench is open-source, and so is Endee. If you want to run this benchmark on your own dataset, or just want to see how Endee handles your specific recall/throughput tradeoffs, the fastest way is to spin it up directly at Endee is open-source (Apache 2.0), self-hostable via Docker, or available as a managed service with a free Starter tier. Full docs, quickstarts, and integration guides (LangChain, LlamaIndex, CrewAI) are at docs.endee.io.
If you run your own benchmark against Endee, we'd genuinely like to see the numbers — drop them in the comments or find us on

endee-io / endee

Endee.io – A high-performance vector database, designed to handle up to 1B vectors on a single node, delivering significant performance gains through optimized indexing and execution. Also available in cloud https://endee.io/

High-performance open-source vector database for AI search, RAG, semantic search, and hybrid retrieval.

Quick Start • Why Endee • Use Cases • Features • API and Clients • Docs • Contact

Endee: Open-Source Vector Database for AI Search

Endee is a high-performance open-source vector database built for AI search and retrieval workloads. It is designed for teams building RAG pipelines, semantic search, hybrid search, recommendation systems, and filtered vector retrieval APIs that need production-oriented performance and control.

Endee combines vector search with filtering, sparse retrieval support, backup workflows, and deployment flexibility across local builds and Docker-based environments. The project is implemented in C++ and optimized for modern CPU targets, including AVX2, AVX512, NEON, and SVE2.

If you want the fastest path to evaluate Endee locally, start with the Getting Started guide or the hosted docs at docs.endee.io.

Why Endee

Built as a dedicated vector database for…

View on GitHub