Bridge runs keyword and vector retrieval in the same query, on the same machine, in microseconds. Written close to the metal so you don't pay for a search cluster to find four results.
One binary. A small RAM footprint. Sub-millisecond p50. It's what you wish your search bar was.
When this matters
Bridge is for teams whose products live or die on retrieval, and whose latency budget can't spare a network hop.
Every query hits a remote cluster. Cold caches, queue waits, JSON over the wire. Users feel the spinner before they see a result.
Semantic search nails fuzzy intent and faceplants on exact terms. Users type a SKU or a name. Embeddings shrug. The right item is on page three.
A managed search service is the third-largest line on the bill. Most queries return small result sets that fit in L2. The cluster is bored.
You have a 50ms budget for the whole page. Search took 38. There is nothing left for the rest of the request.
How it works
Bridge keeps the whole query inside one machine, one address space, one cache line where it can.
Bridge ships as a static binary or a library you link in. No Java runtime, no node coordinator, no cluster. It runs next to your application.
Every request fans out to a sparse lane (BM25 over a compressed posting list) and a dense lane (HNSW over your embeddings). Both lanes run in parallel, in the same address space.
The scanner is written in Rust with SIMD intrinsics. Posting lists, vectors, and result heaps live in arenas that don't allocate per query. Cache stays warm.
Results from both lanes merge with RRF, so an exact-match SKU and a semantically close phrase land in the same top ten. Tunable, or hand it your own scorer.
What ships
Bridge is shaped like a library, priced like infrastructure, and benchmarked like a database.
Embed it as a library, run it as a sidecar, or call it over a Unix socket. No coordinator, no quorum, no rolling restarts.
BM25 catches the exact terms. HNSW catches the intent. Reciprocal-rank fusion gives you a top-10 that's right on both axes, without picking a side.
Sub-millisecond p50 on a million-doc corpus on commodity hardware. Hot path is allocation-free. RAM cost is a function of your data, not your traffic.
Bridge
1.2 GB
Vector DB · cloud
6 nodes
Search cluster
8 nodes
Postgres + pgvector
4 GB
Why Bridge
Bridge does the same retrieval in less code, less RAM, and less time, because it's written that way on purpose.
01
No round trip to a search cluster, no JSON serialization tax. Bridge lives in your process, reads from mapped memory, and returns before a network call could even start.
02
BM25 and embeddings answer different questions about the same query. Bridge runs them together so a SKU and a vibe both end up on the first page. No re-rank pipeline to glue together.
What Bridge isn't
The category is crowded with bigger systems. Here's what makes Bridge structurally different.
Vector-only stores collapse on exact-term queries. Bridge keeps a real keyword index alongside the vector one, and fuses them on every query. Neither lane is bolted on.
No coordinators, no shards to rebalance, no JVM heap to tune. Bridge is a process. You scale it the way you scale your app, because it lives there.
Text is the hot path. If you bring image or audio embeddings, Bridge will index them in the same dense lane and treat them like any other vector. We don't pretend it's the headline.
Common questions
Rust on the hot path, with hand-tuned SIMD for vector distance and posting-list scans. The library exposes C, Python, Go, and Node bindings so you can call it from whatever your service is written in.
Two write paths. A streaming ingest API for incremental updates, and an offline build for cold starts. Indexes are mmap files. Hot reloads are atomic and don't block readers.
Bring your own. Bridge stores and searches vectors of any dimension. We ship reference adapters for OpenAI, Cohere, and a handful of self-hosted text encoders, but the engine is model-agnostic.
Yes, but it's not the headline. If your encoder produces a fixed-dim vector, Bridge will index it in the dense lane and search it the same way. Multi-modal is supported, not assumed.
A single Bridge process handles tens of millions of documents on a normal box. Above that, run multiple shards behind a thin router. There is no orchestration layer to operate.
The core engine is. The managed build (replication, snapshots, observability, hosted control plane) is the commercial product.
Pricing
The library is open. The managed product is what you reach for the day pager duty starts to matter.
Plan 01
Free · MIT
The engine, on your hardware
The Bridge library and CLI. Everything you need to embed hybrid search in your product. Self-hosted, no telemetry, no rate limits.
Plan 02
From $299/mo
For shipping product teams
A hosted Bridge cluster with replication, snapshots, and a control plane. Usage-based on indexed documents, not queries.
Plan 03
Custom
Single-tenant deployment
Self-hosted in your VPC, on-prem, or air-gapped. For regulated environments and high-volume products that need a human on call.
§ 03 · Engagement intake
01 / Start a brief
We staff small and senior, scope by phase, and end on a written deliverable. We don’t sell decks or hours.
If we’re not the right team for the job, we say so on the first call. The bar is production, not pitch.
02 / Where to find us
Montreal, Quebec
Satellite office