Short answers to the questions that come up most, from what QQL is to how it relates to Qdrant and the SDKs.
What is QQL?
QQL stands for Qdrant Query Language: a typed, declarative language for Qdrant. It gives you one surface for retrieval, filtering, point mutations, schema, and policy-safe AST rewriting.
Is QQL a SQL dialect?
No. QQL borrows SQL's readable shape (QUERY ... FROM ... WHERE ... LIMIT), but each statement plans to Qdrant operations — vector retrieval, filtering, mutations, and collection management — rather than a relational engine.
Does QQL replace Qdrant, or does it only work with Qdrant?
It only works with Qdrant, and it does not replace it: Qdrant is the execution target. Statements lower to Qdrant REST or gRPC routes, or run against the in-process edge backend.
How is QQL different from Qdrant's REST API or client SDKs?
The SDKs expose typed request builders per language; QQL is one reviewable statement that runs unchanged from Rust, Python, Node.js, WebAssembly, or the CLI, with trusted filters injectable into the AST before planning.
Which runtimes ship today?
Rust crates, native Python and Node.js bindings, a ~2.5 MB WASM package, the qql CLI, and a VS Code extension with live diagnostics.
How does multitenancy work?
Parse untrusted QQL, then inject a trusted tenant filter into the AST before planning. SHARD routing is a separate locality concern and can run alongside the filter.
Is it production-ready?
It is young: v0.5.0. Fail-closed defaults, OpenAPI contract tests, a conformance corpus, and a public gaps document. The API surface is stabilizing, not frozen.
Can I try it without a cluster?
The WASM parser runs fully offline in the browser. To execute, point the playground at Docker or your Qdrant URL, or run qql-edge for local HNSW storage.