In LangMem
You're building on LangChain / LangGraph and want memory native to that stack.
Comparison
nlqdb vs LangMem
Pick LangMem if you want long-term memory wired into a LangGraph agent — semantic, episodic, and procedural memory the LLM extracts and consolidates for you. Pick nlqdb if your agent also needs to aggregate that memory: GROUP BY, JOIN, and HAVING over structured rows it provisions and migrates itself in plain English.
The same goal, two ways.
> distinct users who asked about pricing each week this quarter
In your HTML
<nlq-data goal="distinct users who asked about pricing each week this quarter"></nlq-data>The aggregation LangMem's similarity search can't run — it returns the memories most relevant to a query, not a COUNT(DISTINCT) per week; nlqdb answers it as SQL over the agent's own memory.
What's different
Four dimensions that decide it
| Dimension | nlqdb | LangMem | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | LangMem extracts and searches memories through its SDK; it has no NL→SQL compiler over a relational store. | ||
| Aggregations + reporting queries (GROUP BY / JOIN / HAVING over memory) | LangMem returns the memories most similar to a query; it has no query planner to aggregate across them. | ||
| Semantic / episodic / procedural memory (LLM-managed) | A unified API over fact, experience, and behavior memory is LangMem's core primitive; nlqdb stores typed rows, not LLM-extracted memory objects. |
Show 6 more rows
| Dimension | nlqdb | LangMem | Note |
|---|---|---|---|
| Background memory manager (auto extract / consolidate / update) | LangMem's manager reviews conversations and decides what to store, update, or forget; nlqdb persists exactly the rows the agent writes. | ||
| Procedural memory / prompt self-optimization | |||
| Auto-migration via NL ('add a `priority` field') | |||
| MCP server (agent-callable) | LangMem is an in-process Python SDK (memory tools the agent calls inside a LangGraph app), not an MCP server; nlqdb's MCP exposes `nlqdb_query` / `nlqdb_list_databases` / `nlqdb_describe`, and `nlqdb_query` materialises Postgres on first reference. | ||
| Vector / semantic recall over stored memory | Similarity search over stored memories is LangMem's lane; nlqdb answers with structured SQL and ships no embedding-based recall today. | ||
| Open source / self-hostable | LangMem is an open-source LangChain SDK (PyPI `langmem`), self-hosted inside your app. 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 recall facts.
- You store structured rows the agent later reports over ('deals per stage this quarter').
- The schema should evolve as the agent learns ('add a `priority` field') via English.
- You want a framework-agnostic data layer, not memory tools locked to LangGraph.
When to choose LangMem
- You're building on LangChain / LangGraph and want memory native to that stack.
- You need semantic, episodic, and procedural memory the LLM extracts and consolidates automatically.
- Memory is prose facts retrieved by similarity — relevant-fact recall over typed SQL aggregation.
- You want procedural memory: the agent refines its own prompts and behavior over time.
Questions buyers ask
- Can I use LangMem for memory management and nlqdb for analytics over the same data?
- Yes — they compose. LangMem extracts and consolidates memories inside the LangGraph agent; nlqdb is the analytical store the agent queries with SQL. Use LangMem for 'what does the agent remember about Kendra' and nlqdb for 'average deal size per stage across everything the agent logged'.
- Does nlqdb extract and consolidate memories automatically like LangMem?
- No. nlqdb persists exactly the rows the agent writes; it has no LLM background manager deciding what to remember, update, or forget. If automatic semantic / episodic / procedural extraction is core to your design, LangMem is the right shape; nlqdb's contract is relational SQL over the rows the agent provisions.
- Is nlqdb tied to LangChain / LangGraph like LangMem?
- No. LangMem integrates most seamlessly with LangGraph's BaseStore and the LangGraph Platform. nlqdb is framework-agnostic — any runtime (Claude, Cursor, Cline, or a LangGraph agent) calls it over HTTP or MCP, so the data layer isn't coupled to one agent stack.
- Can LangMem aggregate an agent's memory the way nlqdb can?
- Not relationally. LangMem retrieves memories by similarity and its background manager consolidates them, but neither returns a GROUP BY / JOIN / HAVING result set. nlqdb compiles the English question to SQL and runs it over typed rows, so the agent gets a real aggregation, not a ranked list of matches.
- Can my AI agent provision its own store with LangMem the way it can with nlqdb?
- LangMem stores memories in a backend you configure through LangGraph's BaseStore (Postgres, a vector DB, or KV) — it doesn't stand up an isolated relational database the agent migrates. nlqdb's MCP `nlqdb_query` materialises a tenant-scoped Postgres plus schema on first reference, so a Claude / Cursor / Cline agent provisions and migrates 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 →