In Milvus
Your agent recalls by semantic similarity over millions-to-billions of embeddings.
Comparison
nlqdb vs Milvus
Pick Milvus if your agent recalls by similarity at scale — billions of embeddings, ANN search with metadata filters and hybrid dense + sparse ranking. Pick nlqdb if your agent must aggregate what it stored: GROUP BY, JOIN, and HAVING over typed rows it provisions in plain English. Milvus ranks the nearest vectors; nlqdb counts, groups, and reports over the rows.
The same goal, two ways.
> tool calls per category this month, only categories with more than 50 calls
In your HTML
<nlq-data goal="tool calls per category this month, only categories with more than 50 calls"></nlq-data>The HAVING-filtered aggregation Milvus has no operator for — its vector search ranks the nearest embeddings with a metadata filter, and even its scalar group-by has no HAVING threshold; nlqdb answers it as SQL over the agent's own memory.
What's different
Four dimensions that decide it
| Dimension | nlqdb | Milvus | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | Milvus exposes a vector-search + scalar-filter API (SDKs / REST / gRPC); it has no English-to-SQL compiler. | ||
| Aggregations + reporting queries (GROUP BY / JOIN / HAVING over memory) | Milvus `query` filters rows; single-collection scalar group-by aggregation (`count(*)` / sum / avg via `group_by_fields`) is new in Milvus 3.0 (the v3.0-beta pre-release); it ships no relational JOIN and no HAVING. | ||
| Vector similarity / ANN search over embeddings | HNSW / IVF / DiskANN / GPU indexes at billion-vector scale are Milvus's core; nlqdb stores typed rows and ships no embedding or ANN search today. |
Show 5 more rows
| Dimension | nlqdb | Milvus | Note |
|---|---|---|---|
| Hybrid dense + sparse / full-text retrieval ranking | Milvus fuses dense vectors with sparse / BM25 full-text into one ranked result; nlqdb has no similarity ranking — it returns exact SQL result sets. | ||
| Auto-migration via NL ('add a `priority` field') | nlqdb migrates the schema from English with a diff-preview; Milvus collections have a fixed schema you alter via the SDK, not a typed-column NL migration. | ||
| MCP server (agent-callable) | Milvus's `mcp-server-milvus` exposes vector / text / hybrid search + query over collections; nlqdb's `nlqdb_query` materialises Postgres on first reference and runs aggregating SQL. | ||
| Runs with no backend to host (embeddable element / hosted API) | Milvus Lite embeds in Python and Zilliz Cloud is managed, but there's no HTML element; nlqdb is one `<nlq-data>` element or a hosted agent-callable API. | ||
| Open source / self-hostable | Milvus 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 rank nearest vectors.
- You want a database provisioned and migrated from English, not a vector index to operate.
- You store typed rows the agent later reports over ('tool calls per category this week').
- You want exact SQL counts and filters, not an approximate-nearest-neighbour relevance ranking.
When to choose Milvus
- Your agent recalls by semantic similarity over millions-to-billions of embeddings.
- You need ANN indexes (HNSW / IVF / DiskANN / GPU) tuned for recall-vs-latency at scale.
- Hybrid dense + sparse / full-text search ranking is the retrieval job, not relational reporting.
- You want a self-hostable Apache-2.0 vector engine with a managed Zilliz Cloud option.
Questions buyers ask
- Can I use Milvus for similarity recall and nlqdb for analytics over the same agent memory?
- Yes — they compose. Milvus handles 'find the most similar past facts to this query' via ANN search over embeddings; nlqdb handles 'how many facts did the agent log per category this month' via SQL. Run Milvus as the semantic-recall layer and nlqdb as the analytical store the agent queries with GROUP BY / JOIN / HAVING.
- Does nlqdb do vector / ANN search like Milvus?
- No. nlqdb is Postgres-first — typed rows queried with exact SQL, not embeddings ranked by approximate nearest neighbour. If billion-scale similarity recall is the job, Milvus is the right shape; nlqdb's contract is relational SQL over the rows the agent provisions in plain English.
- Milvus can filter and count rows — isn't that the same as nlqdb's SQL?
- Only partly. Milvus `query` applies a boolean filter, and single-collection scalar group-by aggregation (`count(*)`, sum, avg via `group_by_fields`) arrives in Milvus 3.0 (the v3.0-beta pre-release) — but it has no relational JOIN across collections and no HAVING. nlqdb compiles those to SQL and runs them in Postgres. Milvus answers 'which vectors are nearest, filtered'; nlqdb answers 'how many, grouped by what, joined across tables, above which threshold'.
- Milvus 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; Milvus is Apache-2.0 today and self-hosts full-featured (Milvus Lite, Standalone, or Distributed), with managed Zilliz Cloud as an option. They differ on the query model — Milvus does vector ANN search, nlqdb does relational SQL.
- Can my AI agent provision its own store with Milvus the way it can with nlqdb?
- Milvus's `mcp-server-milvus` lets an agent search and query collections you've created in a Milvus instance you operate (self-hosted or Zilliz Cloud) — the agent gets a vector index, 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 →