In Weaviate
Your agent recalls by hybrid search — BM25 keyword fused with vector similarity over text.
Comparison
nlqdb vs Weaviate
Pick Weaviate if your agent recalls by hybrid search — BM25 keyword fused with vector similarity — at enterprise scale with multi-tenancy, replication, and RBAC. Pick nlqdb if your agent must aggregate what it stored: GROUP BY, JOIN, and HAVING over typed rows it provisions in plain English. Weaviate ranks the relevant; 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 Weaviate's hybrid search can't run — it ranks the most relevant objects, 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 | Weaviate | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | Weaviate takes a vector, a BM25 query, or a hybrid blend plus a metadata filter; it has no English-to-SQL compiler. | ||
| Aggregations + reporting queries (GROUP BY / JOIN / HAVING over memory) | Weaviate returns ranked nearest objects; it ships no SQL engine, no joins, and no transactions across collections. | ||
| Vector / semantic similarity search over memory | Nearest-neighbour over embeddings is core to Weaviate; nlqdb stores typed rows and ships no embedding search today. |
Show 5 more rows
| Dimension | nlqdb | Weaviate | Note |
|---|---|---|---|
| Hybrid search (BM25 keyword + vector) over stored documents | First-class fused BM25 + dense ranking is Weaviate'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; Weaviate filters by metadata around the hybrid / nearest-neighbour search. | ||
| Auto-migration via NL ('add a `priority` field') | |||
| MCP server (agent-callable) | Weaviate's `mcp-server-weaviate` inserts objects and runs hybrid search; nlqdb's `nlqdb_query` materialises Postgres on first reference and runs aggregating SQL. | ||
| Open source / self-hostable | Weaviate is BSD-3 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 fused similarity + keyword ranking, over memory.
- The schema should evolve as the agent learns ('add a `priority` field') via English.
When to choose Weaviate
- Your agent recalls by hybrid search — BM25 keyword fused with vector similarity over text.
- You need enterprise scale: built-in multi-tenancy, replication, and RBAC across many namespaces.
- RAG context, reranking, or multimodal retrieval is the job, not relational reporting.
- You want an open-source store you can self-host full-featured under BSD-3.
Questions buyers ask
- Can I use Weaviate for hybrid recall and nlqdb for analytics over the same agent memory?
- Yes — they compose. Weaviate handles 'find the passages most relevant to this question' via fused BM25 + vector ranking; nlqdb handles 'how many tools did the agent call per category this week' via SQL. Run Weaviate 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 Weaviate?
- No. nlqdb is Postgres-first — typed rows queried with exact SQL, not embeddings fused with BM25 and ranked by relevance. If hybrid keyword-plus-semantic search over text is the job, Weaviate is the right shape; nlqdb's contract is relational SQL over the rows the agent provisions.
- Weaviate is open source and self-hostable — is nlqdb?
- nlqdb is source-available under FSL 1.1 (Functional Source License), which auto-converts to Apache 2.0 two years after each release; Weaviate is BSD-3 today and self-hosts full-featured. Both let you keep your data; they differ on the query model, not on lock-in — Weaviate does hybrid recall, nlqdb does relational SQL.
- Weaviate has metadata filtering — isn't that the same as nlqdb's SQL WHERE?
- Not quite. Weaviate's metadata filter narrows candidates around a hybrid or 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 objects. Different jobs: one ranks the relevant, the other computes answers.
- Can my AI agent provision its own store with Weaviate the way it can with nlqdb?
- Weaviate's `mcp-server-weaviate` can insert objects and run hybrid search, but the agent gets a vector store, 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 →