Supabase vs Busabase: The Difference Is the Memory-and-Rules Layer

It arrived as two short messages, in the middle of an ordinary conversation:

"Does Busabase have a built-in framework for memory and rules?"

"Is that the biggest difference between you and Supabase?"

Yes — and it is worth answering properly, because the short version is easy to get wrong. The difference between Supabase and Busabase is not that one is a database and the other is not. It is this:

A database stores. Busabase remembers, works by the rules, and keeps the receipts.

Supabase is a database: it holds your application's data, reliably and at scale. Agent memory can live there — Garry Tan's GBrain keeps its shared mode on Supabase. But the memory's structure, the rules your agents follow, the discipline of writing back, and the history and review of every change are not things a database ships. On Supabase, you build that layer yourself. In Busabase, it is built in: Bases are the memory, Docs are standing policy, Skills are the rules, and every write travels as a Change Request with an author and a history. This article walks through both sides honestly — including where Supabase is simply the right tool.

Supabase is a database — a very good one

Supabase calls itself the Postgres development platform, and that is exactly what it is. Every project is a full Postgres database, surrounded by the pieces an application backend needs: Authentication with Row Level Security, Storage for large files, Realtime data synchronization, Edge Functions for serverless code, Data APIs, and Vector — storing, indexing, and searching embeddings in the same Postgres. It is open source, and it is very good at this job. If you are shipping an application, this is a serious, sensible foundation.

Notice what that list is: storage and the services around storage. A database holds rows, files, and vectors faithfully. It does not know what a "memory" is. It has no opinion about which facts an agent should keep, how a person, a company, and a decision relate, what your standing rules are, or who is allowed to change what an agent wrote yesterday.

That distinction matters because of a sentence that sounds true and is only half true: "You can store agent memory in Supabase." You can store it there the way you can store anything there. GBrain is the proof — and the proof of the other half, too. Tan runs GBrain's shared deployment on Supabase Postgres with pgvector, and his own brain has grown to 155,795 pages, 24,589 people, and 5,340 companies. But none of that structure came from the database. GBrain itself is the layer above it: a repository of Markdown pages with its own conventions, a retrieval engine over the stored chunks, a library of skills that tell agents how to ingest, enrich, and maintain the brain, and dozens of scheduled jobs doing that maintenance overnight. Supabase stores GBrain's data. GBrain is the memory-and-rules framework — and Tan had to design and build it himself.

That is not a criticism of either project. It is a job description. The question is only whether you want to do that job yourself.

Schematic — the two layers and what each one holds, not product UI.

On a bare database, the framework is five more projects

Suppose you decide to give your agents a real memory on top of a database you operate. Storage is day one. Then the actual framework work begins — five pieces, each small in isolation, each unforgiving if skipped:

1. A structure for memory. What counts as one memory? How are people, companies, meetings, and decisions represented, and how do they link? In a database this is a schema you design; in a pile of files it is a convention you enforce. Either way, you design it, and every agent has to write to it the same way.
2. Retrieval. Stored is not remembered. Something has to decide what gets pulled into an agent's context for this task — search, ranking, graph traversal, synthesis. GBrain's retrieval layer, with its own evaluation repository, exists because this piece alone is a project.
3. A place for rules — and enforcement. Your standing policy ("never promise a date", "prices always come from the current table") has to live somewhere agents actually read before acting, and its authority cannot rest on a prompt's politeness. Rules buried in one agent's configuration die with that agent.
4. Write-back discipline. Memory only compounds if results return to it: after every task, with sources, deduplicated, in the structure from piece one. Nothing in a database makes an agent do this. It is a convention — until you build the machinery that makes it the default.
5. Approval and permissions. Agents write fast and occasionally wrong. Which writes land immediately, which wait for a person, who can read the sensitive parts, and how a bad write is traced and reversed — a database gives you roles and row-level security as raw materials, not a review workflow with diffs a person can judge.

GBrain is admired precisely because one person built all five, well, and kept them coherent at 155,000-page scale. Most teams will not — not because they can't, but because the framework is a second product hiding inside the first one.

Busabase: the framework is the product

Busabase is the layer above a database, built to be exactly those five pieces — so that "agent memory" is not a project but a workspace you open. It runs on Postgres (or an embedded PGlite) itself; its README says plainly that it is the workspace on top, not a replacement for your app's database. What it adds is the framework:

• Bases are the memory layer. People, decisions, projects, and lessons are typed records with relations — readable by you at a glance, queryable by any connected agent, structured the same way for both. Memory has a shape, and the shape is shared.
• Docs are standing policy. The durable guidance — what belongs in the base, what never goes in, where the red lines are — lives in documents in the same workspace, versioned like everything else, instead of in one agent's system prompt.
• Skills are the rules, as first-class nodes. A Skill is an agent-readable file tree that lives in the workspace next to the Bases it governs. Agents read it before they act; it changes only through Change Requests, so a rule's current version and its history are the same object. And skills compound: lessons an agent files as experience records can be reviewed, adopted, and promoted into the Skill — the loop our earlier guide on building a self-improving agent walks through in full.
• Playbooks make the rules findable. Every Skill and every node's custom prompts are collected into one catalog the agent searches before starting a job — so "how do we do this here?" has one answer, looked up the same way by every agent, instead of five habits in five tools.
• Workflows are the framework's moving parts. A Workflow is a process drawn as a graph, living in the same tree as the records it acts on — and it runs. It can be started manually, or triggered when records change: that is the runtime's first version, and it is in place today. Recent releases sharpen it: trigger only when a field changes, or changes to a specific value, so a record that is already ready and gets edited again does not set it off; run on a schedule — at intervals, daily, or weekly, calculated in the editor's own time zone; call webhooks with custom headers, so endpoints that require authentication are reachable; and pick an approval step's approver from the member list instead of a typed-in address. The point is the same one Skills make: the process is written down once, in the workspace, and then executed the same way every time — not re-invented per run, and not living only inside one agent.
• Change Requests are the governance. Every agent write — a record, a rule, a document — travels as a Change Request with a message, a field-level diff, an author, and a history. Permissions decide whether it merges on the spot — the default for a key with write access — or waits in an inbox for a person. A credential capped at changeRequest level can only propose, never land a change on its own. That is what makes an agent's write authoritative rather than merely stored: there is a named proposer, a visible diff, and a decision that survives the merge.

A starter shape, if you set this up today:

Starter design — adapt the names and fields to your own work.

Schematic — GBrain is the example of the left column done well, by hand.

Side by side

Neither column is a verdict on the other. They are different layers that happen to both involve storing things — which is exactly why the comparison confuses people.

Stack them: which layer, when

Choose Supabase when you are building an application's backend: user accounts, realtime features, file storage, SQL and vector queries at application scale. That is its home turf, and it is excellent there. Busabase is not a candidate for that job — it does not pretend to be an app backend.

Choose Busabase when the thing being stored is your agents' memory and the rules they work by: the people and decisions they must remember, the policy they must follow, the writes a person must be able to review. That framework is the product.

Use both when both jobs exist — which, for agent-heavy teams, is most of the time. Application data lives in Supabase. The agents' shared memory, standing policy, and skills live in Busabase, where any agent you connect — Claude Code, Codex, Cursor, your own — reads and writes under the same governance. The layers stack because they were never competing: Busabase itself runs on Postgres.

Next: an ontology for the record layer (in development)

The framework's next layer is in development: an ontology for the record layer. It is not available yet, so here is what it is for. You define the business objects your team talks about — Company, Contact, Deal — and the links between them on top of the Bases you already have, without copying the underlying data anywhere. People and agents then share one vocabulary, and each object traces back to its source record. The ontology lives under the same governance as everything else in this article: changes to it go through Change Requests. Memory that is structured is findable; memory whose entities and relationships are explicitly defined is interpretable the same way by every agent you will ever connect. Its status, stated plainly: in development, not shipped. This article's claims do not depend on it.

FAQ

Can I use Supabase as my agent's memory? You can store memory there — GBrain does. What you cannot get from the database is the framework: the memory structure, the rules layer, the write-back discipline, and the review of agent writes are yours to design and maintain. If that build is the interesting part for you, it is a legitimate project. If it isn't, it is the part Busabase removes.

What makes an AI agent's write to a database authoritative? Not the write itself — what happens around it. In Busabase, an agent's write is a Change Request: it names its author, shows a field-level diff, and either merges under permissions you set or waits for a person's decision, with the whole trail kept after the merge. A row that simply appeared in a table has storage. A change with provenance has authority.

Do I have to choose one? No. They answer different questions. Supabase answers "where does my application's data live?" Busabase answers "where do my agents remember, and under what rules?" Many teams will run both, one layer above the other.

Start with the layer you're missing

If your agents already have a place to store things but keep forgetting, re-deciding, and writing without a trace, the missing piece is not more storage — it is the framework above it. The previous article in this series, Everyone Is About to Have Their Own Database, installs the open-source Busabase edition in one command and includes the copy-paste prompt that hands the whole setup to your agent. For the taxonomy behind this comparison, see Agent Memory vs Knowledge Base vs System of Record; for the evergreen selection page, see Busabase vs Supabase; and for how the two fit next to Notion, Busabase as a Notion + Supabase hybrid.

• Code and self-hosting: github.com/busabase/busabase
• Desktop edition: busabase.com/download
• Docs: busabase.com/docs