Skip to main content
LambdaDB implements the vector lake as a collection of serverless functions and resources within AWS. It persists collection documents, vectors, and indexes to S3-backed object storage. User requests flow through a regional Gateway, which routes them to either Control or Data functions, and the Builder function periodically commits buffered data to object storage. LambdaDB serverless architecture diagram

Gateway

Gateway verifies the project API key in user requests for targeted projects. If the key is valid, it checks whether the project exceeds its configured rate limit. It then routes the request to either Control or Data functions, based on the type of work needed.

Control functions

Control functions handle collection lifecycle operations and data versioning for branches, tags, and aliases. They also perform maintenance tasks, such as adjusting the number of virtual shards for each collection to enable parallel query execution based on collection size, triggered by EventBridge Scheduler. They use DynamoDB for storing metadata and coordinating concurrent readers, writers, and background tasks. Shards are an internal execution detail; LambdaDB does not expose shard-count or placement settings to users. Separately, applications can configure collection partitions and use partitionFilter to narrow a request’s physical search scope.

Data functions

Data functions perform actual data writes and reads.

The write path

When the Writer function receives a request to upsert, update, or delete records in a collection, it records the request details for the selected branch in a log with a monotonically increasing sequence number. This request log is written into a durable write buffer before returning a response to the client. Later, the Builder writes buffered logs to object storage in batches and advances the branch head when data is committed. Immutable snapshots provide consistent read points for branches and tags, while aliases route reads to a named branch or tag.

The read path

When a query is received, the Router resolves the requested ref and then invokes Executor functions based on the number of virtual shards assigned to the collection. A strongly consistent read is available only when the request directly selects a branch; the Router includes eligible buffered writes, excluding pending bulk imports. If that pending payload exceeds the consistent-read limit, the request returns 429. Each executor scans its assigned shard data and returns top candidates. The Router merges and deduplicates candidates, includes buffered results when required, and returns the final result set. When requested, native reranking evaluates globally merged, deduplicated candidates before the final size limit. Its model and criteria are selected per query, with provider credentials managed by LambdaDB. On a partitioned collection, partitionFilter restricts the search to selected physical partitions; unselected partitions are not searched. Without it, all partitions remain in the search scope. Internal sharding distributes the work within that scope rather than selecting the application’s tenant, session, or repository data.