In Qdrant
Your agent recalls by vector search and you want quantization to cut RAM and cost.
Comparison
nlqdb vs Qdrant
Pick Qdrant if your agent recalls by fast, memory-efficient vector search — quantized HNSW with dense-plus-sparse hybrid ranking, self-hostable on Apache-2.0. Pick nlqdb if your agent must aggregate what it stored: GROUP BY, JOIN, and HAVING over typed rows it provisions in plain English. Qdrant ranks the relevant cheaply; nlqdb counts, groups, and reports.
The same goal, two ways.
> calls per tool category this week, only categories above 20 calls
In your HTML
<nlq-data goal="calls per tool category this week, only categories above 20 calls"></nlq-data>The HAVING-filtered aggregation Qdrant's quantized vector search can't run — it ranks the most relevant points, not a GROUP BY / COUNT with a threshold; nlqdb answers it as SQL over the agent's own memory.
What's different
Four dimensions that decide it
| Dimension | nlqdb | Qdrant | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | Qdrant takes a dense vector, a sparse vector, or a hybrid blend plus a metadata filter; it has no English-to-SQL compiler. | ||
| Aggregations + reporting queries (GROUP BY / JOIN / HAVING over memory) | Qdrant returns ranked nearest points; it ships no SQL engine, no joins, and no transactions across collections. Quantization makes recall cheaper, not relational. | ||
| Vector / semantic similarity search over memory | Quantized HNSW nearest-neighbour over embeddings is core to Qdrant; nlqdb stores typed rows and ships no embedding search today. |
Show 5 more rows
| Dimension | nlqdb | Qdrant | Note |
|---|---|---|---|
| Hybrid search (dense + sparse vectors) over stored documents | Native dense + sparse fusion via the Query API is Qdrant's headline; nlqdb matches text with SQL LIKE / pattern predicates, not a fused-rank index. | ||
| Filtering on retrieval | nlqdb filters with exact SQL WHERE over typed columns; Qdrant filters by payload metadata around the nearest-neighbour search. | ||
| Auto-migration via NL ('add a `priority` field') | |||
| MCP server (agent-callable) | Qdrant's `mcp-server-qdrant` stores and finds memories by vector (`qdrant-store` / `qdrant-find`); nlqdb's `nlqdb_query` materialises Postgres on first reference and runs aggregating SQL. | ||
| Open source / self-hostable | Qdrant is Apache-2.0 and self-hosts full-featured; nlqdb is source-available on FSL 1.1-ALv2, auto-converting to Apache 2.0 after two years. |
shipped · partial · not shipped
When to choose nlqdb
- Your agent must aggregate its memory (GROUP BY, JOIN, HAVING), not just rank relevant items.
- You store structured rows the agent later reports over ('calls per tool this week').
- You want exact filters and counts, not a quantized similarity ranking, over memory.
- The schema should evolve as the agent learns ('add a `priority` field') via English.
When to choose Qdrant
- Your agent recalls by vector search and you want quantization to cut RAM and cost.
- You need native hybrid search — dense plus sparse vectors fused in one Query API call.
- Raw recall throughput and self-hosting on a permissive Apache-2.0 licence matter most.
- RAG context or semantic retrieval is the job, not relational reporting over rows.
Questions buyers ask
- Can I use Qdrant for vector recall and nlqdb for analytics over the same agent memory?
- Yes — they compose. Qdrant handles 'find the points most relevant to this question' via quantized HNSW with dense-plus-sparse ranking; nlqdb handles 'how many tools did the agent call per category this week' via SQL. Run Qdrant as the recall layer and nlqdb as the analytical store the agent queries with GROUP BY / JOIN / HAVING.
- Does nlqdb do vector or hybrid search like Qdrant?
- No. nlqdb is Postgres-first — typed rows queried with exact SQL, not quantized embeddings fused with sparse vectors and ranked by relevance. If fast, memory-efficient semantic search over text is the job, Qdrant is the right shape; nlqdb's contract is relational SQL over the rows the agent provisions.
- Qdrant is Apache-2.0 and self-hostable — is nlqdb open source too?
- nlqdb is source-available under FSL 1.1 (Functional Source License), which auto-converts to Apache 2.0 two years after each release; Qdrant is Apache-2.0 today and self-hosts full-featured. Both let you keep your data; they differ on the query model, not on lock-in — Qdrant does quantized vector recall, nlqdb does relational SQL.
- Qdrant has payload filtering — isn't that the same as nlqdb's SQL WHERE?
- Not quite. Qdrant's payload filter narrows candidates around a nearest-neighbour search, so the result is still a relevance ranking. nlqdb runs exact SQL — WHERE, GROUP BY, COUNT, JOIN — and returns a precise result set, not the top-k most relevant points. Different jobs: one ranks the relevant, the other computes answers.
- Can my AI agent provision its own store with Qdrant the way it can with nlqdb?
- Qdrant's `mcp-server-qdrant` can store and find memories by vector, but the agent gets a vector collection, not a relational database it can aggregate or migrate. nlqdb's MCP `nlqdb_query` materialises a tenant-scoped Postgres plus schema on first reference, so a Claude / Cursor / Cline agent stands up and reports over its data layer end-to-end without a human in the loop.
Try nlqdb in 30 seconds
No sign-in. The anonymous database lasts 72 hours; adopt it with one click if you keep it.
Start with a goal →