Open Brain (OB1): a self-hosted memory layer for every AI you use

What Open Brain actually stores, and who it is for

Open Brain is not a notes app, and the README says so directly: it describes the project as "a database with vector search and an open protocol" built so that every AI tool you use shares the same persistent memory. That framing matters, because it tells you what the unit of value is. The unit is a thought, stored in your own Postgres instance with a vector column for retrieval, and the product is the access path other tools get to that store.

The audience is narrower than the tagline suggests. The README's Getting Started section offers two routes: a Setup Guide that builds the full system (database, AI gateway, Slack capture, MCP server) in about 45 minutes with no coding experience needed, or an AI-assisted setup for people who would rather point Cursor or Claude Code at the repository. Both routes assume you are willing to run infrastructure. If you want memory that works the moment you install a desktop app, this is the wrong shape of project. If you have ever wanted Cursor to know what you told ChatGPT last week, the shape is right.

One database, one gateway, one channel: the data flow

The architecture is visible in the repository layout rather than in a diagram. There is a server/ directory, an integrations/ directory, a schemas/ directory and a primitives/ directory. The recent contributions table names several of the moving parts concretely: an MCP server, an entity-extraction worker, a thought-enrichment backfill, and a kubernetes-deployment integration. So the flow is roughly: a capture surface writes a thought into Postgres, a worker enriches it, and MCP exposes read and write tools to whatever AI client connects.

Slack is the capture channel the README calls out by name, which is a deliberate choice. Capture has to be cheaper than remembering to capture, and a Slack message is about as cheap as it gets. The AI gateway sits between the store and the model providers, which is why one contribution mentions reporting "the real cause when all LLM providers fail": the gateway is a fan-out point, and provider outages surface there.

The protocol layer is what makes this more than a personal database. Because access goes through MCP, a client does not need a bespoke integration with Open Brain. It needs an MCP client. That is the whole bet, and it is a reasonable one given how many editors and chat clients now speak the protocol.

Installing Open Brain and capturing your first thought

There is no package to install. The README points at docs/01-getting-started.md for the full build, and the repository has no releases, so there is no versioned artifact to pin. Clone the repository and read the setup guide before running anything:

git clone https://github.com/NateBJones-Projects/OB1.git
cd OB1

The guide walks through four components: the database, the AI gateway, Slack capture and the MCP server. Because the store is Supabase, expect a project URL and a service key to be part of that configuration. The repository also ships an AI-assisted path, which is the faster route if you already use an agentic editor:

# in Cursor, Claude Code or a similar tool, with the repo open
# follow docs/04-ai-assisted-setup.md and let the agent run the steps

The README states this produces the same system through a different workflow. Either way, the first real use is a capture. The README's companion prompts are five prompts intended to help you migrate existing memories, discover use cases and build the capture habit, so the intended first session is not an empty test row but a migration of things you already wrote down elsewhere. Expect the first capture to be a Slack message that later shows up when an AI client queries the store through MCP.

Where Open Brain gets awkward

The recent contributions list is the most honest signal in the repository. It is dominated by fixes to things that were subtly wrong: a household item storing details as an escaped JSON string, double-encoded metadata writes in thought enrichment, UUID id pagination in backfills, an MCP GET route causing an SSE reconnect storm, non-POST MCP requests rejected with 405 to prevent a GET handshake hang, a default model id that 404s on OpenRouter. None of these are fatal. All of them are the kind of bug you only find after you have data in the system.

That is the real limitation. Open Brain is a set of recipes and integrations wired to a schema you own, and the schema is the part that hurts when it changes. The README does not document rollback, and with no releases there is no version boundary to roll back to. If you run this, your upgrade process is reading diffs in schemas/ and recipes/ and deciding what to apply. For a solo operator that is fine. For a team that expects a changelog, it is not.

The second constraint is the LLM gateway. Entity extraction and enrichment call out to model providers, which means your memory layer has an external dependency and a per-thought cost. The repository shows a worker that handles provider failure, but failure handling is not the same as offline operation. If you want a memory store that works with no network and no API keys, this is not it.

How it differs from hosted memory features

The obvious alternative is the memory that ships inside the tools themselves: ChatGPT's memory, Claude's memory, Cursor's project context. Those are genuinely easier. They require no database, no gateway and no Slack workspace, and they work the moment you enable them. The difference in approach is ownership and reach. Hosted memory is per-vendor and readable only by that vendor's product. Open Brain inverts it: the store is the durable artifact and the AI tools are clients that come and go. The README's phrasing is that Claude, ChatGPT, Cursor and Claude Code all plug into one brain.

A second alternative is a general personal knowledge base with an API, where you store notes and add search yourself. That gives you the store but not the protocol. You would be writing the MCP server that Open Brain already ships, and you would be writing the enrichment worker too. The trade is control versus time.

The honest comparison is not features but failure modes. With hosted memory, the failure is that a vendor changes or removes the feature and your context is gone or locked. With Open Brain, the failure is that you are the operator: your Supabase project, your gateway keys, your schema migrations. Pick the failure you can live with.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10, so it is being worked on. That is a statement about activity, not about support. There are no releases, which means no semantic versioning, no upgrade notes and no supported version to pin. The practical upgrade path is to read the recent contributions table and the directories it references, then apply the changes you need by hand. The table is generated from GitHub and the README notes it refreshes daily, so it is a usable changelog substitute, but it is a list of merged pull requests, not a migration guide.

The licence is the other thing to check yourself. The repository metadata reports NOASSERTION, and the README does not state terms. LICENSE.md exists at the top level, so the answer is in the file, not in the metadata. Read it before you build anything commercial on top of this, and if the terms matter to your organisation, get that read by someone qualified rather than by a tool. Nothing here is legal advice, and a NOASSERTION label is a prompt to go look, not an answer.

Editorial conclusion

Adopt Open Brain if you already pay for Supabase or are willing to, you want your AI tools reading one shared thought store instead of per-app memory silos, and you accept that the project ships no releases and no rollback story. Do not adopt it if you need a packaged installer, a supported upgrade path, or a licence you can read in one line: the repository carries a NOASSERTION licence and the README never states terms. Before committing, verify three things in your own copy of the repo: that docs/01-getting-started.md still matches the schemas/ directory, that the MCP server starts under the transport your client expects, and that you can restore a Supabase backup, because nothing in the README describes undoing a schema change.

Frequently asked questions

Official sources

1. Issues
2. NateBJones-Projects/OB1 on GitHub
3. README