In Chroma
Your agent recalls by semantic similarity — nearest-neighbour over text or document embeddings.
Comparison
nlqdb vs Chroma
Pick Chroma if your agent recalls by similarity and you want an open-source store you can run embedded or self-hosted — nearest-neighbour plus full-text and metadata filtering. Pick nlqdb if your agent must aggregate what it stored: GROUP BY, JOIN, and HAVING over typed rows it provisions in plain English. Chroma finds the similar; nlqdb counts, groups, and ranks.
The same goal, two ways.
> the 10 tools the agent called most this week, ranked by call count
In your HTML
<nlq-data goal="the 10 tools the agent called most this week, ranked by call count"></nlq-data>The aggregation Chroma's similarity search can't run — it returns the documents nearest a query, not a GROUP BY / COUNT ranking; nlqdb answers it as SQL over the agent's own memory.
What's different
Four dimensions that decide it
| Dimension | nlqdb | Chroma | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | Chroma takes a query embedding (or text) plus a metadata filter; it has no English-to-SQL compiler. | ||
| Aggregations + reporting queries (GROUP BY / JOIN / HAVING over memory) | Chroma returns the top-k most similar documents; it ships no SQL engine, no joins, and no transactions. | ||
| Vector / semantic similarity search over memory | Nearest-neighbour over embeddings is Chroma's core primitive; nlqdb stores typed rows and ships no embedding search today. |
Show 5 more rows
| Dimension | nlqdb | Chroma | Note |
|---|---|---|---|
| Full-text search over stored documents | Chroma indexes documents for full-text + vector search; nlqdb matches text with SQL LIKE / pattern predicates, not a ranked text index. | ||
| Filtering on retrieval | nlqdb filters with exact SQL WHERE over typed columns; Chroma filters by metadata around the nearest-neighbour search. | ||
| Auto-migration via NL ('add a `priority` field') | |||
| MCP server (agent-callable) | Chroma's `chroma-mcp` creates collections and adds/queries documents by similarity; nlqdb's `nlqdb_query` materialises Postgres on first reference and runs aggregating SQL. | ||
| Open source / self-hostable | Chroma is Apache-2.0 and runs embedded or self-hosted; 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 find similar items.
- You store structured rows the agent later reports over ('deals per stage this quarter').
- You want exact filters and counts, not approximate nearest-neighbour ranking, over memory.
- The schema should evolve as the agent learns ('add a `priority` field') via English.
When to choose Chroma
- Your agent recalls by semantic similarity — nearest-neighbour over text or document embeddings.
- RAG context or related-document lookup is the job, often with full-text search alongside.
- You want an open-source store you can run embedded in-process or self-host yourself.
- You're prototyping locally and want a zero-config vector store before any cloud.
Questions buyers ask
- Can I use Chroma for semantic recall and nlqdb for analytics over the same agent memory?
- Yes — they compose. Chroma handles 'find the documents most similar to this question' via nearest-neighbour and full-text search; nlqdb handles 'how many tools did the agent call per category this week' via SQL. Run Chroma as the recall layer and nlqdb as the analytical store the agent queries with GROUP BY / JOIN / HAVING.
- Does nlqdb do vector / similarity search like Chroma?
- No. nlqdb is Postgres-first — typed rows queried with exact SQL, not embeddings ranked by distance. If approximate nearest-neighbour search over text or document vectors is the job, Chroma is the right shape; nlqdb's contract is relational SQL over the rows the agent provisions.
- Chroma 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; Chroma is Apache 2.0 today and runs embedded in-process or self-hosted. Both let you keep your data; they differ on the query model, not on lock-in — Chroma does vector + full-text recall, nlqdb does relational SQL.
- Chroma has metadata filtering — isn't that the same as nlqdb's SQL WHERE?
- Not quite. Chroma's metadata filter narrows candidates around a nearest-neighbour search, so the result is still a similarity ranking. nlqdb runs exact SQL — WHERE, GROUP BY, COUNT, JOIN — and returns a precise result set, not the top-k closest documents. Different jobs: one finds similar, the other computes answers.
- Can my AI agent provision its own store with Chroma the way it can with nlqdb?
- Chroma's `chroma-mcp` server can create a collection and add documents, but the agent gets a similarity 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 →