One search engine that does both halves of retrieval.

Dense vector and BM25 keyword in a single index, fused at query time with RRF — and no model, cloud, or agent framework you're required to buy alongside it.

start free → read the docs

5 GB free, no card
$0 for idle namespaces
SaaS · your VPC · on-prem

vf query --namespace support-kb --hybrid

Example language

curl python typescript

curl https://api.vectorforge.dev/v1/namespaces/support-kb/query \
  -H "Authorization: Bearer $VF_KEY" \
  -d '{
    "query_text": "ERR_2041 on annual plan renewal",
    "top_k": 4,
    "hybrid": { "bm25_text": "ERR_2041 on annual plan renewal" },
    "filter": { "lang": "en" },
    "include_content": true,
    "include_metadata": true
  }'

from vectorforge import Client

vf = Client()                      # reads VF_KEY

res = vf.query(
    namespace="support-kb",
    query_text="ERR_2041 on annual plan renewal",
    hybrid=True,                   # vector + bm25, fused with rrf
    top_k=4,
    filter={"lang": "en"},
)

for hit in res.results:
    print(hit.score, hit.id, hit.content)

import { VectorForge } from "vectorforge";

const vf = new VectorForge();

const res = await vf.query({
  namespace: "support-kb",
  queryText: "ERR_2041 on annual plan renewal",
  hybrid: { bm25Text: "ERR_2041 on annual plan renewal" },
  topK: 4,
  filter: { lang: "en" },
});

// rrf fused · 4 hits · vec + bm25 ranks shown

0.941v4 · k1ERR_2041 is returned when a renewal charge is retried after…
0.887v1 · k9Annual plans can be refunded in full within 30 days of the…
0.812v2 · k—Downgrades take effect at the end of the current billing…
0.774v— · k2Error code table: ERR_2038, ERR_2041, ERR_2044 (billing)…

LOOMSTACKPARSEC AINORTHWIND LABSHELIXCAREORBIT DESKFENWAY DATAKETTLEARGUS SEARCH

// 01 — hybrid, not vector-only

Dense retrieval fails silently on the exact terms your users type.

Embeddings handle paraphrase and concept. They underweight rare literal strings — SKUs, error codes, version numbers, statute references — that appear verbatim in one or two documents. The miss doesn't show up as an error; it shows up as a hallucination complaint that won't reproduce in your eval set, because the eval was built from queries that already worked.

✕ a vector DB plus a search cluster plus glue

Both halves, one query, one bill.

Dense and BM25 live in the same index and fuse with RRF at query time. No second cluster to operate, no application-layer merge, no consistency gap between the two.

✕ fusion weights you have to tune per corpus

RRF as the zero-tuning default.

Rank-based fusion ignores score-distribution mismatch, so it holds up across corpora. Weighted fusion is there when you have labelled pairs — most teams never need it.

✕ embeddings required before anything works

Keyword-only is first-class.

A namespace can run pure BM25 with no vectors and no embedding spend. Field boosts, query modes and filters all behave the same way when you add vectors later.

// 02 — the evidence

Neither half wins alone.

Published recall@10 on a public retrieval set: dense-only and sparse-only both leave results on the table, and rank-based fusion recovers most of the gap. Fusion costs about 6ms.

Third-party figures, single corpus. Retrieval quality is corpus-dependent — we publish our methodology so you can reproduce it against your own data before you believe us.

methodology + eval harness →

dense vectors only78%

BM25 keyword only65%

hybrid, RRF fused91%

recall@10 · Supermemory retrieval study, Apr 2026

+6ms

fusion cost at the p50

1 index

not two systems to keep in sync

0 tuning

RRF needs no labelled data

// 03 — neutrality

Every other retrieval product is a wedge for something else.

Retrieval sold by a model vendor exists to move tokens. Retrieval sold by a cloud exists to move consumption. We sell retrieval. There is no first-party embedding model whose revenue depends on your corpus staying where it is, which is why we can make leaving cheap.

the migration nobody solves

Managed re-embed, atomic cutover.

A better embedding model ships every few months, and moving to it means re-embedding the corpus — a quarter of work most teams never schedule. Here it's an operation: name a new embedder profile, we rebuild the index in the background, then swap the manifest under compare-and-swap while readers keep serving the old one. No downtime, no dual-write window, no rewrite.

vf ns reembed support-kb \
  --profile voyage/voyage-3-large \
  --cutover atomic

▸ rebuilding base    12.4M chunks
▸ cutover ready      manifest v41 → v42

No model to sell you

The embedder is a namespace-level setting with a provider catalog — OpenAI, Voyage, Gemini, or an open model we host. Switching cost is published per model.

No cloud to lock you into

Run on our storage, in your own buckets, or in your datacenter. The index format and API are identical, so the deployment target is a procurement decision rather than a rewrite.

No agent framework in the way

Plain HTTP, three SDKs and an MCP surface. Nothing assumes which orchestration library, model provider or agent platform you settled on.

// 04 — what you get

Three systems collapse into one.

Hybrid retrieval

Dense and BM25 in one request with or / and / boolean modes, fused by RRF. Field boosts and query modes are documented, not hidden behind a tuning service.

Embedder profiles

Any provider or a self-hosted open model, configured per namespace. Managed re-embed with atomic cutover turns a model migration into an operation.

Per-namespace economics

$0 for an idle namespace, no per-namespace floor, no per-query minimum. Ten thousand small tenants bills like ten thousand small tenants.

Code-native depth

AST chunking across seven languages, keyword index over symbols and paths, per-branch namespaces, GitHub webhook incremental reindex.

Reranking

Cross-encoder rerank over the fused candidates in the same round trip, priced per call — off by default, one flag to turn on.

Ops you can see

Per-namespace metering over an API, segment compaction, PITR from immutable base blobs and manifest history, audit log export, per-namespace CMEK.

// 05 — code-native retrieval

A retrieval stack that knows what a function is.

General document retrieval chunks code by character count and embeds it with a general-purpose model. We parse it. AST-aware chunking across seven languages, a keyword index over symbol names and file paths, a code-tuned embedder profile as the documented default, and per-branch namespaces kept current by webhook.

AST chunking for Go, Python, TypeScript, Java, Rust, Ruby and C#
BM25 over symbol names, file paths and identifiers — exact-match where it matters most
Per-branch namespaces, so a release branch is its own index
Webhook-driven incremental reindex on push, not a nightly full rebuild

vf repo connect acme/platform \
  --branches main,release/* \
  --chunker ast \
  --embedder managed/code-2

▸ 7 languages parsed     41,882 symbols
▸ keyword index          symbols + paths
▸ webhook registered     push → incremental

$ vf query platform@main \
    "retry budget for the ingest queue" --hybrid

0.94  IngestQueue.retryBudget()   src/queue/ingest.go:212
0.88  backoff schedule notes      docs/runbooks/ingest.md
0.81  QUEUE_RETRY_MAX             config/defaults.yaml

// 06 — deployment

Runs where the data has to live — with the search features at parity.

Most vendors charge a premium to run inside your cloud. You're paying the infrastructure bill, so we discount instead. Nothing about retrieval quality is gated by tier — only operational and compliance surface.

Serverless

saas

$25/mo + usage

Multi-tenant on our storage. Nothing to provision, per-namespace billing, free tier that is actually usable.

storage: VectorForge
search features: full
sla: 99.9%
sso / audit export: add-on

Your buckets

vpc

$1,900/mo + 50% usage

We run the control plane; your cloud account runs the data plane. Vectors and documents never leave your network boundary.

storage: customer's cloud
search features: full parity
sla: 99.95%
cmek / private net: included

On-prem

self-managed

annual, quoted

The same distributed binary via Helm or Compose, air-gapped if required, supported by the team that wrote it.

storage: customer's datacenter
search features: full parity
sla: support-tier
sso / audit export: included

// 07 — the shape of the market

Feature sheets converged. The intersection didn't.

VectorForge compared with S3 Vectors, Google Agent Retrieval and turbopuffer
Capability	VectorForge	S3 Vectors	Google Agent Retrieval	turbopuffer
hybrid in one index	vector + BM25, RRF	vector only	semantic + token, RRF	vector + full-text
managed embeddings	any provider	none	first-party models	none
runs in your account	VPC + on-prem	AWS only	GCP only	BYOC, premium priced
idle namespace cost	$0	storage only	per-deployment floor	scan minimum per query
code-aware retrieval	AST + symbol BM25	—	—	—

Compiled from public vendor documentation and pricing pages, July 2026. Competitor products move fast — tell us if something here is out of date and we'll correct it.

"We came for the price and stayed for the keyword half. Half our support queries are error codes, and dense-only retrieval was quietly missing them — nothing in our eval set caught it."

Dana Whitfield · Staff Engineer, Loomstack

"We replaced a search cluster with a keyword-only namespace in a week, then switched embedding models twice in the following quarter. Neither migration was a project."

Marcus Oyelaran · Head of Platform, Helixcare

// 08 — pricing

Four meters. No per-namespace floor.

Object-storage economics, billed per namespace. A namespace nobody queried this month costs nothing, so ten thousand small tenants is a workload rather than a pricing problem.

storage

$0.06

per GB-month, at the floor of the serverless band

queries

$2.00

per million, 1 GB scanned floor

writes

$0.35

per GB · 50% discount on batch ingest

idle namespace

no per-namespace minimum, ever

Free tier

5 GB stored · 3 namespaces · 1M queries/mo · 1M writes/mo. Hybrid, filters and reranking included — the free tier is the product, not a demo.

create a namespace →

Start on keyword alone

A namespace with no vectors stores about a quarter as much, spends nothing on embeddings, and still answers BM25 queries. Replace a search cluster first, turn embeddings on namespace by namespace when you're ready.

Elasticsearch migration guide →

$25/month platform fee past the free tier. Embeddings through third-party APIs pass through at cost plus 10%; self-hosted open models are billed per million tokens. Every meter is visible per namespace in the console and over the usage API.

$ npm i -g vectorforge && vf init

Own your retrieval layer, not a vendor's roadmap.

5 GB free. Any embedding model. Any cloud, or none of them. Change your mind later without re-indexing a corpus.

start free → talk to an engineer