Over the last few months, I've been experimenting with browser-based AI.
Every demo followed a similar pattern:
- Generate embeddings
- Send them to a server
- Store vectors in a database
- Query them over an API
It works, but something always felt unnecessary.
Modern browsers already have WebGPU, WebAssembly, IndexedDB, Web Workers, and surprisingly powerful JavaScript engines. We can run language models in the browser today, yet most applications still depend on a remote vector database just to perform similarity search.
That made me wonder:
Why isn't there a proper vector database that lives entirely inside the browser?
That question eventually became BrowserVec.
The Problem
When building AI applications that run locally, vector search becomes the missing piece.
Imagine applications like:
- Personal knowledge bases
- AI note-taking apps
- Offline document search
- Browser extensions
- Local RAG
- Privacy-first AI assistants
Generating embeddings in the browser is already possible.
The difficult part is storing, indexing, and searching thousands—or even millions—of vectors efficiently without sending everything to a backend.
Most existing JavaScript libraries either:
- perform brute-force searches,
- are optimized only for Node.js,
- or wrap native implementations that aren't designed specifically for browser environments.
I wanted something built for the browser from the beginning.
What BrowserVec Tries to Solve
BrowserVec is a client-side vector database designed specifically for modern browsers.
Instead of treating the browser as a lightweight client, it treats it as a capable runtime.
The goal is simple:
- Store vectors locally
- Search them efficiently
- Keep data on the user's device
- Use GPU acceleration whenever available
- Fall back gracefully when it isn't
No servers required.
How It Works
At a high level, the flow is straightforward.
Application
│
▼
BrowserVec API
│
▼
Index Selection
│
▼
GPU / WASM / JavaScript
│
▼
Top-K Search
│
▼
Filtered Results
Developers only interact with a simple API.
Internally, BrowserVec decides the most appropriate execution engine depending on the user's browser capabilities.
Why WebGPU?
Similarity search is mostly mathematics.
Thousands (or millions) of vectors require calculating distances continuously.
GPUs are built for exactly this type of workload.
Instead of comparing vectors sequentially on the CPU, BrowserVec performs those calculations in parallel using WebGPU compute shaders whenever possible.
When WebGPU isn't available, it automatically falls back to WebAssembly or JavaScript so applications continue working.
The idea is performance without sacrificing compatibility.
More Than Just Search
As the project evolved, I realized a usable vector database needed much more than fast distance calculations.
Today the project includes support for:
- Flat indexes
- IVF indexes
- HNSW indexes
- Persistent storage using IndexedDB and OPFS
- Metadata filtering
- Import and export
- Background processing with Web Workers
- Optional encryption
- Quantization for reducing memory usage
Each feature was added to solve a practical problem encountered while experimenting with browser-native AI.
Where I Think Browser AI Is Going
The browser has become far more capable than it was a few years ago.
Running language models locally is becoming increasingly common.
Embedding generation is improving rapidly.
Hardware acceleration is available on more devices every year.
I think vector search is the next piece that should feel native in browser applications instead of requiring a server.
Maybe not every application needs millions of vectors.
But many applications need thousands and they shouldn't have to leave the user's device to search them.
What's Next?
There are still plenty of things I'd like to improve.
Some areas I'm actively exploring include:
- Better ANN performance
- Improved GPU scheduling
- More benchmark comparisons
- Additional indexing strategies
- Better developer tooling
- Easier integrations with browser AI frameworks
There's still a lot to learn, but that's part of the fun.
Final Thoughts
BrowserVec started as an experiment.
It gradually became an engineering project that challenged almost every part of browser development—from GPU programming and storage APIs to performance optimization and developer experience.
If you're building browser-native AI applications, I'd genuinely love to hear how you're approaching vector search today.
I'm always interested in feedback, ideas, or even criticism. Those conversations usually end up making the project better.
Top comments (0)