Skip to main content
LambdaDB provides explicit Qdrant-style compatibility clients for Python and TypeScript applications. Use them when you have already moved or plan to move Qdrant data into LambdaDB, but want to keep common Qdrant client calls while you migrate application code. The compatibility clients are not full Qdrant client replacements. They cover the common dense-vector search and RAG subset, map Qdrant points to LambdaDB documents, and raise an explicit unsupported-feature error for behavior that LambdaDB cannot safely emulate.

When to use this path

Use the Qdrant compatibility clients when:
  • Your application already uses Qdrant’s Python or JavaScript/TypeScript SDK.
  • You want a smaller application change than rewriting all query code to LambdaDB native APIs at once.
  • Your workload uses dense vectors, named dense vectors, payload filters, document retrieval, deletes, scroll, or collection metadata checks.
Use LambdaDB native APIs directly when:
  • You are building new application code.
  • You need LambdaDB-specific query features such as lexical plus vector hybrid search.
  • You want the clearest long-term API surface after migration.

Install

Python support is available in lambdadb >= 0.8.2:
TypeScript support is available in @functional-systems/lambdadb >= 0.4.3:

Connection settings

LambdaDB Cloud uses region-specific API base URLs. Use the base URL, project name, and project API key shown for your project in the LambdaDB Cloud console. Do not assume a global default URL or a fixed project name.
Pass those values to the compatibility client instead of a Qdrant URL.

Python

Change the import and client construction explicitly:
Create a collection, write points, and query with Qdrant-style calls:
Python

TypeScript

Change the import and client construction explicitly:
Create a collection, write points, and query with Qdrant-style calls:
TypeScript

Supported Qdrant-style APIs

Data mapping

Payload fields cannot use id or the reserved _qdrant_ prefix.

Payload and vector selectors

Boolean selectors and field-list selectors are supported on query and retrieve paths. Field-list payload selectors are mapped to LambdaDB fields.include where possible and are also applied to the Qdrant-style response payload. Vector-name selectors request vector values from LambdaDB and filter the returned Qdrant-style vector object by Qdrant vector name:
Python
TypeScript
scroll() maps to LambdaDB list documents. Filters are translated to LambdaDB list filters before pagination. When Qdrant-style vector selectors are requested, the compatibility layer requests vector values from LambdaDB and filters the returned vector object while shaping the response. Returned next_offset / nextOffset values are LambdaDB page tokens. Pass the returned token back as the next offset; numeric Qdrant point-ID offsets are not supported.
Python
TypeScript

Filter support

Unsupported behavior

  • Local Qdrant mode, including path and location=":memory:"
  • Sparse vector upsert through the compatibility client
  • Multi-vector comparators
  • Geo payload indexes and geo filters
  • Filtered count
  • Query offset
  • score_threshold
  • HNSW and search tuning semantics beyond warnings

How this fits with the Migration CLI

The LambdaDB Migration CLI moves data from Qdrant to LambdaDB. The Qdrant compatibility clients help reduce application code changes after data is in LambdaDB. For a full Qdrant migration workflow, start with the migration guide:

Migrate from Qdrant

Move Qdrant collections, points, vectors, sparse vectors, and payload indexes to LambdaDB.

SDK reference

Install and use the official LambdaDB SDKs.