Mem0 is the name everyone hears first. If your agent runs in TypeScript, TurboMem bets on a different model i.e embedded memory in your process, not another service to operate. Here is an honest comparison based on hard facts.
If you are building an AI agent that needs to remember things across sessions, you have probably run into Mem0 already. It is one of the most talked about memory layers in the space, well funded and framework agnostic. But if your stack is TypeScript, there is a newer option worth a serious look: TurboMem. It takes a different architectural bet, and for a lot of TS focused companies, that bet pays off.
The core difference: embedded vs server based
This is really the whole story, and it is worth understanding before anything else.
Mem0 is built around a separate memory service. Even in its open source form, the typical setup wires up a Postgres instance with pgvector, or Qdrant, plus optionally Neo4j for graph memory, then talks to that stack either through the Python Memory class or over an HTTP API. Every memory read or write crosses a process boundary.
TurboMem skips that boundary entirely. It runs inside your Node, Bun, or browser process as a native TypeScript library. There is no sidecar, no separate memory server, and no network hop for a local memory call. You call memory.add() or memory.search() and it executes in process, backed by PGlite (a WASM build of Postgres) by default.
If you are shipping a TypeScript product and want memory to behave like any other library you import, this is a meaningfully simpler model.
Getting started
With TurboMem, setup is about as light as it gets:
npm install turbomem
PGlite ships as a dependency, so the default stack (OpenAI embeddings plus PGlite storage) works right after install, no database to provision.
With Mem0, self hosting means standing up actual infrastructure. The typical Docker Compose deployment involves a Postgres container with the pgvector extension, optionally a Neo4j container for graph features, and the Mem0 API server itself. Ports need to be locked to localhost, a reverse proxy needs to sit in front since the default setup ships with no authentication and an open CORS policy. It is a real deployment, not a package install. The alternative is Mem0’s hosted platform, where you trade that setup work for depending on their API.
Neither approach is wrong, they are built for different situations. But if your goal is “add memory to my app” rather than “operate a memory service,” TurboMem’s path is shorter.
Built for TypeScript, not translated into it
Mem0’s core is a Python library. It does ship a TypeScript SDK, but the project’s defaults, examples, and even a chunk of its ecosystem (LangChain, CrewAI, LlamaIndex integrations) are Python first. That is fine if your agent stack is Python. It is friction if it is not.
TurboMem starts from TypeScript. It uses strict typing with Zod validated inputs, runs on Node 20+, Bun, the browser, and edge runtimes, and its adapters target the TypeScript ecosystem directly, including Mastra and the Vercel AI SDK. If your agents are built in TypeScript already, you are not bridging two languages to get memory working.
Where you can actually run it
This is one of the more underrated parts of TurboMem’s design. Its storage layer is pluggable across very different runtimes:
- PGlite for local Node and Bun apps, no external database
- sqlite-vec for SQLite native setups
- Upstash Vector over HTTP for edge runtimes like Cloudflare Workers and Vercel Edge
- Pinecone if you want managed cloud vector storage
- IndexedDB backed PGlite for durable memory directly in the browser, no remote database required
Mem0’s vector store options are broader in raw count (it lists support for 20 plus backends including Qdrant, Chroma, Milvus, and more), which makes sense given how much longer it has existed and how many teams have contributed integrations. But that flexibility assumes you are operating a server somewhere to talk to those backends. TurboMem’s shorter list is built specifically around runtimes that do not want a server at all, including the browser and the edge, which Mem0’s server oriented model is not really designed for.
Cost and ongoing overhead
With TurboMem, there is nothing extra running. No database container, no API server to monitor, no reverse proxy to secure. Your memory layer scales exactly the way your app process scales.
With Mem0 self hosted, you are operating additional services: Postgres, potentially Neo4j, the API layer, all needing monitoring, patching, and their own uptime story. With Mem0’s hosted platform, you avoid running that infrastructure yourself, but you are paying for and depending on an external API for every memory call, and Mem0’s graph memory feature specifically is gated behind their $249 a month Pro tier.
TurboMem is Apache 2.0 licensed and fully usable today with no paid tier required to get the full library, including LLM extraction, deduplication, and scoped search. A managed TurboMem Cloud is in the works for teams that eventually want a hosted option, but it is not a requirement to use the product.
Where Mem0 is still the better call
To be fair, Mem0 is not a worse project, it is a different one, and it genuinely wins on a few axes:
- If your stack spans multiple languages, or your agents are built in Python, Mem0’s maturity and native Python support matter more than an embedded TypeScript library ever will.
- Mem0 has a much larger integration surface today (LangChain, CrewAI, LlamaIndex, and more), simply from being around longer and having more contributors.
If you need a cross language, managed memory platform, Mem0 is a very reasonable default.
The bottom line
Mem0 solves memory by giving you a service to talk to. TurboMem solves it by giving you a library to import. Neither approach is universally correct, it depends on what you are building.
But if you are building a TypeScript agent, and you want memory that behaves like the rest of your dependencies (installed with npm, running in your process, typed the way your codebase already is), TurboMem is the more natural fit. No sidecar, no separate server to operate, and it runs anywhere your TypeScript already runs, including the browser and the edge.
Get started
If the embedded model fits your stack, the fastest way to see it in your own agent is the getting started guide: install the package, set your OpenAI key, call init(), and store your first scoped memories.
From there, the configuration guide covers embeddings, extraction, and scoping, and the architecture overview walks through the full pipeline.
For more on why TypeScript teams often skip a separate memory server in the first place, read Why Your TypeScript Agent Doesn’t Need a Memory Server.
If you have questions or feedback, reach out on the contact page or email arneesh@turbomem.dev. We are building turbomem in the open on GitHub.
The original blog post is at: Turbomem Blog
Top comments (0)