Serverless, without the ceilings

The Vector Lake for
AI Memory

Store, search, and version-control AI knowledge and memory.

Free plan: 1 PB reads & 2 GB writes/mo · no card

280 ms P99 @ 128 QPS · 22M vectors19 s to ingest 1M vectors$0 when idle
A cross-section of the LambdaDB vector lake: memory, knowledge, vectors, and metadata settle as layers in one durable basin. An on-demand search beam drops in from above, ripples the surface, and the result rises back out: nothing running when idle.memoryknowledgevectorsmetadatadocs · vectors · metadata · memoryTHE VECTOR LAKEcontinuous ingestcontinuous ingeston-demand searchon-demand searchnothing running when idle
In production since 2025
Scaling

Scales instantly with the burst. $0 when idle.

Hybrid search fans out one request into parallel queries; agents stack writes on top of every read. The burst lands on your biggest day.

Provisioned capacity bills you for idle; serverless quotas throttle you at peak. Either way, the ceiling is yours to manage.

A traffic chart over time with a small legend: your workload (solid ink), vendor limits (dashed), and LambdaDB capacity (orange). The workload spikes past both limit lines, provisioned capacity and serverless vendor quota; the band between the two limits is shaded amber and labeled degraded; the region above the quota is shaded red and labeled outage. In low-traffic stretches, the space between the provisioned line and the workload is shaded and labeled idle but still billed. The orange LambdaDB capacity line follows the workload the whole way.your workloadvendor limitsLambdaDB capacitydb traffic ↑timeidle · still billedserverless vendor quotaprovisioned capacityoutagedegradedvendor quotaprovisioned capacityLambdaDBidle · still billedLambdaDB capacity
idle you still pay fordegraded: above provisioned capacityoutage: above vendor quotaLambdaDB: follows the load, no ceilings
Version control

Test your AI memory like you test your code.

Agents write to their own memory as they run, and every write is a potential regression.

Your database keeps only the latest version of what your AI knows: no history, no comparison, no undo.

What one version history unlocks

Swap embedding models on a branch, and promote only what beats production.

Roll back to any tagged version when data gets poisoned or overwritten.

Pin reads to a tag, so any answer can be reproduced against the exact version and fixed.

Four steps on one collection timeline, snapshot-adoption model. Step 1: tag v1 pins the current state and production serves it. Step 2: a branch forks off copy-on-write. Step 3: evals pass. Step 4: the branch snapshot is adopted wholesale as version v2 of the collection, with no merge and no conflicts; the branch is deleted and the production alias moves from v1 to v2.alias: productionalias: productionkb1tag v1tag v2v1 stays for rollback2embed-v2 · copy-on-write3evals passed4adopt the snapshot as v2whole state · no merge · no conflicts
The same four steps, laid out vertically for small screens. Step 1: tag v1 pins the current state and the production alias hangs under it. Step 2: a branch forks off copy-on-write. Step 3: evals pass on the branch. Step 4: the branch snapshot is adopted as tag v2 and the production alias now hangs under v2.kbtag v11production2embed-v2 · copy-on-writeevals passed34tag v2production
1Tag v1 pins today's state. Production serves it.2Branch off copy-on-write: full data, no copy.3Run evals on the branch until they pass.4Adopt the branch snapshot as v2 (no merge). Delete the branch; production moves to v2.
The primitives underneath
Tags

Freeze a state as an immutable version.

Aliases

Point traffic at a version and repoint without code changes.

Branches

A connected line of versions inside a collection.

Versioned Search

Search any version: branch, tag, or alias.

Reproducible Reads

Pin reads to a tag; any answer can be re-run against that exact version.

Features

Production-grade search, included in every plan.

No platform fees or minimums. Hybrid search, filters, consistent reads, and EN · KO · JA analyzers on every plan, including free.

Lexical, vector, filters: one request

Lucene query strings with fuzzy matching and boosting, k-NN with pre-filters, and both rankings fused with RRF. English, Korean, and Japanese analyzers built in.

Read the docs
ts
// Lexical + vector, fused with RRF: one request
const results = await client.collection("kb").query({
size: 10,
query: {
rrf: [
{ queryString: {
query: 'title:(refund OR policy)^2.5 OR content:lambdadb~2' } },
{ knn: {
filter: { queryString: { query: "metadata.type:guide" } },
field: "content_embedding",
queryVector: await embed("refund policy update"),
k: 10 } },
],
},
});
// Lexical + vector, fused with RRF
const kb = client.collection("kb");
const results = await kb.query({
size: 10,
query: {
rrf: [
{ queryString: {
query:
'title:policy^2 OR refund~1' } },
{ knn: {
filter: { queryString: {
query: "metadata.type:guide" } },
field: "content_embedding",
queryVector:
await embed("refund policy"),
k: 10 } },
],
},
});

Works with your AI stack. MCP server for Claude, Cursor, and any MCP client · Python, TypeScript, and Go SDKs · REST · LangChain · MCP setup guide

Guides for migrating from Elasticsearch, Pinecone, and Qdrant →

Safety

Isolated, encrypted, recoverable.

What happens to your data, in plain terms.

Isolation

API keys are scoped to one project. A key can't read another project's data.

Data residency

Data lives in the AWS region you choose, and stays there.

Durability

Object storage underneath, replicated across availability zones.

Recovery

Roll back to any tagged version, and search past versions to see what changed.

Encrypted at rest and in transit · SOC 2 Type II in progress.

Stay on the Frontier

May 19, 2026

Qdrant vs. LambdaDB: A 10M-Vector Benchmark

Read more →
Apr 16, 2026

From Context Engineering to Harness Engineering

Read more →

FAQFrequently asked questions

Because nothing is running while you're idle. Your documents, vectors, and indexes live in object storage, a durable layer with no compute attached. Query and indexing workers spin up per request and disappear when the burst passes. With no always-on index servers, there's nothing to bill between requests: you pay for storage, reads, and writes only.

Because your data sits in one durable layer, object storage, and search runs over it on demand: the same shape as a data lake, but indexed for millisecond hybrid search instead of batch analytics. One copy of the data, queryable and versionable like code.

It is, if you hit cold storage on every query. LambdaDB keeps frequently-read data in a cache layer the system manages for you, so most reads never touch the object store. Measured on 22M Cohere-V3 vectors (1024-dim): P99 280 ms at 128 QPS. The limits and pricing behind that number are public in our docs.

In durable object storage, in the region you choose, isolated per project. A write is durable once acknowledged. With consistent reads enabled, it's queryable the moment the call returns.

Either way works. Bring vectors from any model, or point a field at an embedding provider and LambdaDB handles embedding at write time and query time.

Most serverless databases hide the servers but keep your data attached to them, so read caps appear per namespace, and the official fix is reserved compute billed by the hour. LambdaDB separates storage from compute completely: reads scale with the burst without sharding, pinning, or reserved nodes, and idle costs $0.

Didn't find your question? Ask in the community Slack or talk to us.

Start small. Experiment safely.
Scale what works.

Hybrid search with no clusters to size. Branch, evaluate, and promote with aliases.

View pricing →