In Cognee
Your agent recalls by meaning and relationships — a knowledge graph fused with vector similarity.
Comparison
nlqdb vs Cognee
Pick Cognee if your agent recalls by reasoning over a knowledge graph — entities and relationships fused with vector similarity for context-rich semantic recall. Pick nlqdb if your agent must aggregate what it stored: GROUP BY, JOIN, and HAVING over typed rows it provisions in plain English. Cognee connects and recalls 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 Cognee's knowledge-graph search can't run — it recalls relevant, connected context, 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 | Cognee | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | Cognee's `search()` runs hybrid vector + graph-traversal recall over a knowledge graph; it has no English-to-SQL compiler. | ||
| Aggregations + reporting queries (GROUP BY / JOIN / HAVING over memory) | Cognee returns relevant, graph-connected context; it ships no SQL engine for GROUP BY / JOIN / HAVING over typed rows. | ||
| Knowledge-graph construction from unstructured data | Cognee's `cognify()` builds entities + relationships + an ontology from ingested documents; nlqdb stores typed relational rows, not a graph. |
Show 5 more rows
| Dimension | nlqdb | Cognee | Note |
|---|---|---|---|
| Hybrid semantic + graph-traversal recall over memory | Vector similarity fused with graph relationships (14 search modes) is Cognee's core; nlqdb stores typed rows and ships no embedding or graph recall today. | ||
| Auto-migration via NL ('add a `priority` field') | nlqdb migrates the schema from English with a diff-preview; Cognee's graph evolves as data is re-cognified, but there's no typed-column migration step. | ||
| MCP server (agent-callable) | Cognee's `cognee-mcp` exposes cognify / search over the knowledge graph; nlqdb's `nlqdb_query` materialises Postgres on first reference and runs aggregating SQL. | ||
| Runs with no backend to host (embeddable element / hosted API) | Cognee is a Python package you host and wire to LLM keys plus graph and vector backends; nlqdb is one `<nlq-data>` element or a hosted agent-callable API. | ||
| Open source / self-hostable | Cognee is Apache-2.0 and self-hosts full-featured; nlqdb is source-available on FSL 1.1, auto-converting to Apache 2.0 two years after each release. |
shipped · partial · not shipped
When to choose nlqdb
- Your agent must aggregate its memory (GROUP BY, JOIN, HAVING), not traverse a graph for context.
- You want a database provisioned and migrated from English, not a Python pipeline to host.
- You store typed rows the agent later reports over ('calls per tool this week').
- You want exact SQL counts and filters, not a semantic + graph relevance ranking.
When to choose Cognee
- Your agent recalls by meaning and relationships — a knowledge graph fused with vector similarity.
- You ingest unstructured documents and want an ontology built and evolved automatically.
- You want a self-hostable Apache-2.0 framework with pluggable graph and vector backends.
- Context-rich semantic recall for RAG is the job, not relational reporting over rows.
Questions buyers ask
- Can I use Cognee for knowledge-graph recall and nlqdb for analytics over the same agent memory?
- Yes — they compose. Cognee handles 'pull the relevant, connected context for this question' via vector + graph traversal; nlqdb handles 'how many tools did the agent call per category this week' via SQL. Run Cognee as the semantic-recall layer and nlqdb as the analytical store the agent queries with GROUP BY / JOIN / HAVING.
- Does nlqdb build a knowledge graph like Cognee?
- No. nlqdb is Postgres-first — typed rows queried with exact SQL, not entities and relationships fused with embeddings into a graph. If reasoning over connected context and semantic recall is the job, Cognee is the right shape; nlqdb's contract is relational SQL over the rows the agent provisions in plain English.
- Cognee 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; Cognee is Apache-2.0 today and self-hosts full-featured. They differ on the query model, not on lock-in — Cognee does hybrid vector + graph recall, nlqdb does relational SQL.
- Cognee's search returns connected context — isn't that the same as nlqdb's SQL query?
- Not quite. Cognee's `search()` returns the entities and relationships most relevant to a query — a recall result. nlqdb runs exact SQL — WHERE, GROUP BY, COUNT, JOIN — and returns a precise result set, not the most relevant context. Different jobs: one recalls and connects, the other computes answers.
- Can my AI agent provision its own store with Cognee the way it can with nlqdb?
- Cognee's `cognee-mcp` lets an agent cognify data into and search a knowledge graph, but the agent gets a graph engine you've hosted and wired to backends — 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 →