Skip to main content
Every OMP method — add, search, context, and the rest — works identically no matter which backend you choose. Your application code calls the same functions with the same arguments; only the Memory(...) constructor line changes when you want a different provider. This means you can prototype with Postgres, deploy with Mem0, and let each user pick their own backend, all without modifying the logic that reads and writes memories.

Swap the constructor, keep the code

The examples below all use the same add and search calls. The only difference is the first line.

Let users choose their own backend

You can read the provider name and configuration from user settings and forward them directly to the constructor. Your application never needs a conditional branch per provider.
This pattern is how multi-tenant apps can give each user sovereignty over their own memory storage.

Install extras

The core openmem package includes the Postgres adapter. Each third-party provider requires its own extras group:
1

Postgres (included by default)

2

Mem0

3

Supermemory

4

Letta

Store provider config in environment variables

Keep credentials out of your source code. Store the provider name and any API keys or URLs as environment variables, then read them at startup. This also makes it trivial to change providers per deployment environment without touching application code.

Asynchronous ingestion on hosted providers

Mem0 and Supermemory may return status="queued" on add(). The memory is accepted but ingested asynchronously on the provider’s infrastructure. Check the status field on the returned MemoryRecord before assuming the record is immediately searchable.
Postgres always returns status="done" — writes are synchronous and the record is immediately searchable.