FAISS vs. The World: Why We Still Build on Facebook's Foundation

I always struggle a bit when people ask why we built on FAISS instead of using one of the shiny new vector databases. After all, Pinecone exists. Milvus is mature. Weaviate has a beautiful API. Why would anyone in their right mind choose to work with a C++ library designed for research at Facebook?

The short answer is: performance. The long answer is... also performance, but with more nuance. Let me explain by telling you what happened when we benchmarked everything.

The Great Benchmark (2023)

When we started building our code intelligence platform, we needed vector search that could handle tens of millions of code embeddings with sub-10ms latency. This isn't an unusual requirement—it's table stakes for production. So we did what any responsible engineering team would do: we benchmarked everything.

The test was simple. 10 million 768-dimensional vectors (code embeddings from our training corpus). 1000 queries. K=10 nearest neighbors. Measured latency at p50, p95, and p99. Also measured recall against brute-force ground truth. Standard stuff.

Look at those numbers. FAISS isn't just faster—it's significantly faster. The p99 latency difference means that under load, FAISS serves requests in 8ms while others spike to 15-25ms. For interactive applications, that's the difference between "snappy" and "sluggish."

And this is FAISS with the default OpenMP parallelism, the basic IVF-PQ index, and none of our optimizations. Raw, off-the-shelf FAISS still beats systems that have been tuned for production. That tells you something about the underlying engineering.

Why FAISS is Different: First Principles

Here's the thing about FAISS that most people don't appreciate: it wasn't built to be a product. It was built to be the fastest possible implementation of similarity search algorithms. No compromises for usability. No abstractions for extensibility. Just raw, brutal performance.

The FAISS team at Meta Research did things that product engineers wouldn't do. They wrote custom SIMD kernels in assembly. They optimized cache utilization to the byte level. They restructured algorithms to minimize memory bandwidth, because at scale, memory bandwidth is the bottleneck, not compute.

The Algorithm Zoo

FAISS doesn't commit to one indexing strategy. It supports a menagerie of algorithms, each optimized for different tradeoffs:

Most vector databases pick one or two algorithms and optimize around them. FAISS gives you the full toolkit. Want IVF with PQ codes and HNSW coarse quantization? Build it. Want flat indexes for small datasets and switch to IVF at scale? Supported. This flexibility means you can always find the right tradeoff for your specific workload.

The GPU Story: Where FAISS Really Shines

We haven't even talked about GPU search yet. FAISS has first-class GPU support—not "GPU acceleration" as a marketing checkbox, but actual optimized GPU kernels that can search billions of vectors in milliseconds.

The GPU implementation is remarkably sophisticated. It handles multi-GPU search with sharding. It has specialized kernels for different GPU generations. It can mix CPU and GPU computation for hybrid workloads. And crucially, it was written by people who actually understand GPU programming, not people who wrapped cuBLAS and called it done.

31,000 queries per second on a billion vectors. On a single GPU. That's the kind of performance that lets you build interactive applications at scales that would be impossible otherwise.

The Downsides: Why We Built FAISS Extended

I've been gushing about FAISS, but let me be honest about its problems. Because we spent significant engineering effort fixing them.

These limitations are why vector databases exist. Pinecone, Milvus, and friends solve these problems. They wrap similar algorithms in production-ready infrastructure. But—and this is the key insight—they often sacrifice 2-3x performance in the process.

Our bet was different: what if we could add the production capabilities while keeping the FAISS performance? What if we could have our cake and eat it too?

FAISS Extended: Best of Both Worlds

That's what FAISS Extended is. We took the FAISS core—all those beautiful SIMD kernels and optimized algorithms—and built the production layer ourselves. Not a wrapper. Not an abstraction. Direct modifications to the FAISS codebase that add capabilities without sacrificing performance.

Benchmark: FAISS Extended vs. The Competition

Same test as before. 10 million vectors, 768 dimensions, K=10 nearest neighbors. But now we include FAISS Extended with our optimizations.

FAISS Extended matches the best in class on latency AND supports 12,000 updates per second. That's the production capability of a modern vector database with the raw performance of FAISS. This is what happens when you add features instead of adding abstraction.

When to Use What

I'm not going to claim FAISS Extended is the right choice for everyone. Different problems require different solutions. Here's our honest assessment:

The Bottom Line

FAISS is still the foundation of high-performance vector search. The core algorithms and implementations are unmatched. What was missing was the production layer—updates, deletes, caching, composable parallelism.

We built FAISS Extended because we needed both: FAISS-level performance AND production-grade operations. Two years and a lot of C++ later, we have it. The benchmarks speak for themselves.

Is it more work than using a managed service? Yes. Is it worth it when you need the performance? Absolutely. That's the trade-off. We made our choice. Now you can make yours.