DEV Community: Max S.

AI Agent Memory: Most of It Should Be a Database Table

Max S. — Fri, 30 Oct 2026 11:07:20 +0000

I don't trust AI agent memory. It keeps facts that stopped being true and can't tell which version is current.

Every memory demo I've seen goes the same way. You tell the agent your favorite color, it saves "User's favorite color is blue" somewhere, and a week later it proudly tells you your favorite color is blue. Cool. Now change your favorite color.

The agent ends up with two memories that disagree, a vector search that returns both, and a model that has to guess which one is still true. Run that for a few months and you have a pile of half-true sentences about your users that nobody can clean up.

My take: anything that can be declarative should be declarative. If a fact has one correct value, it goes in a column. The agent is an operator. It reads and updates data. It shouldn't be a warehouse for everything a user ever said.

I wanted to see if that holds up outside my own head, so I built a small demo.

TL;DR: Store facts about users (diet, city, plan, language) as plain table columns that the agent reads and updates. Keep vector memory for stuff that has no structure, like notes and past conversations. Scope both to the user in the database, so the agent can't recall what someone else told it.

What is AI agent memory?

AI agent memory is whatever an agent carries over from earlier interactions. Most guides split it in two: short-term memory is the current conversation sitting in the context window, and long-term memory is whatever survives between sessions.

Long-term memory usually gets three labels borrowed from cognitive science. Here's the standard list, plus one column most guides skip:

Type	What it holds	Example	Where I'd store it
Short-term (working)	The current conversation	"Make that function async"	Context window
Semantic	Facts about the user	"User is vegetarian"	A table column
Episodic	Things that happened	"Refund issued on March 3"	An events table with timestamps
Procedural	How to do things	"Always confirm before deleting"	Your prompt or your code

Most of what people call long-term memory already has a natural home in a database. Only the leftovers, like free-form notes or "what did we talk about last time," need embeddings.

The problem with "the agent will remember"

I built a small demo on Nhost and stored the same user two ways in one Postgres database:

Vector memory: an agent_memories table where the agent saves sentences from conversations, with embeddings for semantic search. This is roughly how most memory tools work.
Declarative memory: a user_profile table with one row per user and plain columns like diet, city and preferred_language.

Then I fed in a year of a fictional user's life. January: steak every week, apartment in Berlin. By March they'd gone vegetarian, and in June they moved to Lisbon. On top of that, about ten unrelated memories about work and hobbies.

"What does this user eat?"

Here are the top 5 results from vector memory:

1. Jan 8   I eat steak pretty much every week
2. Mar 12  I went vegetarian last month
3. Jan 22  I work as a product designer at a fintech startup
4. Jan 15  I live in Berlin
5. Aug 9   I prefer meetings before lunch

The outdated fact came first. Vector search compares meaning and ignores dates, so "steak every week" beats "went vegetarian" for a question about food. The agent gets both and has to guess which one is still true, with the wrong one on top.

It happened again with "where does this user live?" "I live in Berlin" from January ranked first, and "I moved to Lisbon" from June came second.

A top-5 search also returns five results whether or not five are relevant, so "I prefer meetings before lunch" counts as an answer about food. You can add a similarity cutoff and a recency boost, but then you're tuning a ranking formula to imitate what a single UPDATE already does. And "I went vegetarian last month" only makes sense if you know it was saved in March. Pull it out a year later and "last month" means nothing.

The table returns one row: diet = vegetarian.

"Forget where I live"

In the table, that's city = null. One field, done.

With vector memory, you have to find every sentence that says where the user lives and delete each one. Here's what a semantic search for "where I live" found:

1. Jan 15  I live in Berlin
2. Jun 3   I moved to Lisbon
3. Feb 5   I'm training for a half marathon in the spring
4. Apr 10  I spent Easter hiking in the Dolomites
5. Oct 3   I joined a pottery class on Thursday evenings

The two right rows are at the top, and the search didn't miss any. But it can't tell you where "about where I live" stops, so if the agent deletes the top five, the user also loses their half marathon, their Easter hike and their pottery class.

Another user asks about steak

I added a second user, B, who lives in Madrid and has a steak memory of their own: a medium-rare steak is their favorite dinner.

When B searched for "steak," B got their own steak memory first and then the rest of their own memories. When A searched for "steak," A got A's. A plain read of both tables showed the same thing: A sees 14 memories and one profile, all A's, and B sees 5 memories and one profile, all B's.

Both approaches passed this one, because both tables have the same rule: a user can only read their own rows. The rule lives in the database, so it holds no matter what the agent decides to do.

AI agent memory architecture

Here's the setup I'd build in 2026:

The agent acts as the user. It calls your API with the user's session, so it gets the same permissions that user has and can't read anything they couldn't.
Facts live in tables: profile, preferences, plan, settings. The agent reads them and changes them with normal updates.
Events go in an events table. Orders, tickets, refunds, each with a timestamp. That's your episodic memory, and SQL already knows how to query it.
Vectors cover the rest: notes, chat summaries, documents. Searchable by meaning and scoped to the user like everything else.

The agent decides what to read and what to change.

Agent memory management: rules I'd follow

If a fact has one correct value, make it a column.
When a fact changes, update it. Appending a new sentence leaves the old one behind.
"Forget this" should be a delete or an update you can point to.
Put permissions in the database, so every memory is scoped to its owner before the agent sees it.
Save events with timestamps, so "what happened last month" becomes a plain query.
Use embeddings only for text that doesn't fit a schema, and expect fuzzy results there.

Where tools like Mem0 fit

Memory tools like Mem0 pull "memories" out of conversations with an LLM, then use another LLM call to decide whether to add, update or delete them. For the messy leftovers, like notes and chat history, that's a reasonable approach.

For facts with one correct value, I'd still pick a column in my own database. I can read it, change it and delete it without asking a model which sentence wins.

How I built it on Nhost

The whole demo runs on one Nhost project. It's a Postgres database with auth and permission rules on top, so both kinds of memory sit in one database under the same rules.

The tables

Declarative memory is a regular table with one row per user:

create table user_profile (
  user_id uuid primary key references auth.users (id),
  diet text,
  city text,
  preferred_language text,
  updated_at timestamptz not null default now()
);

Vector memory is a table too. agent_memories stores the sentences, and Graphite, the AI service in Nhost, fills in an embeddings column for every row. When the text of a row changes, a small trigger marks it as outdated and Graphite embeds it again on its next sync. I didn't write any embedding code.

Permissions

Both tables get the same rule for the user role: you only see rows where user_id is your own ID.

{ "filter": { "user_id": { "_eq": "X-Hasura-User-Id" } } }

In the demo, users can only read. In a real app you'd also let them update their own profile row, so "forget where I live" goes through the same rule.

Search

Graphite adds a semantic search query for the table, and it runs through the same permission rule as any other query:

query Recall($query: String!) {
  graphiteSearchAgentMemories(args: { query: $query, amount: 50 }, limit: 5) {
    content
    created_at
  }
}

That's why user B never saw user A's steak. Nobody had to remember a WHERE clause in the search code.

Forgetting

On the declarative side, "forget where I live" is one update:

mutation Forget($id: uuid!) {
  update_user_profile_by_pk(pk_columns: { user_id: $id }, _set: { city: null }) {
    city
  }
}

Graphite's API is evolving, so check the Nhost docs for the current setup.

FAQ

Does an AI agent need a vector database for memory?

For most of it, no. Facts about a user fit in table columns, and events fit in a table with timestamps. You only need embeddings for unstructured text, and pgvector inside Postgres handles that without a second database.

What's the difference between short-term and long-term agent memory?

Short-term memory is the current conversation in the model's context window, and it's gone when the session ends. Long-term memory is stored outside the model and loaded back in when it's relevant, across sessions.

How do you make an AI agent forget something?

If the fact lives in a column, you update or delete that field. If it only lives in vector memory, you have to search for every sentence that mentions it and delete those, and you can't be fully sure the search found them all.

How do you stop an agent from remembering other users' data?

Scope memory in the database. If every memory row has an owner and the agent queries with the user's permissions, it never gets other users' rows back. An instruction in the prompt can be ignored, and a filter in the agent's code only works if every query remembers to add it.

Your agent needs less memory than you think

Most of what an agent "remembers" is data your app should already own: profile fields, settings, events. Give the agent access to that, scoped to the user, and keep the fuzzy memory small.

What does your agent remember right now that should've been a column? Tell me in the comments.

pgvector is enough. Here are the two bugs you'll ship anyway.

Max S. — Fri, 23 Oct 2026 09:04:31 +0000

"Do we need Pinecone for this?"

If you're adding AI search to an app in 2026, someone on your team has asked this. The internet's answer is pretty settled by now: no, keep your embeddings in Postgres with pgvector.

I agree. I also work at Nhost, a backend built on Postgres, so yes, I'm biased.

But most pgvector tutorials I've read stop at the same spot. Add a vector column, insert embeddings, run a similarity query, ship it. So I built a support ticket search and kept going past that spot. Two bugs showed up almost right away.

TL;DR: pgvector handles the search fine. It won't keep your embeddings fresh when the data changes, and it won't make sure search results respect who's allowed to see what. Both fail silently. At the end I'll show how Nhost Graphite takes care of both.

Bug 1: stale embeddings

Support tickets change. A customer adds details. An agent fixes the title. Someone finally pastes the actual error message.

Here's the usual setup:

// creating a ticket
const embedding = await embed(ticket.body);
await db.query(
  'INSERT INTO tickets (customer_id, title, body, embedding) VALUES ($1, $2, $3, $4)',
  [ticket.customerId, ticket.title, ticket.body, embedding]
);

// updating a ticket, somewhere else in the codebase
await db.query('UPDATE tickets SET body = $1 WHERE id = $2', [newBody, ticketId]);

The insert creates an embedding. The update doesn't.

What happens: nothing. No errors, no failing tests. Search quietly gets worse, because it's matching against what your tickets said last week.

The fix is some kind of sync job. Mark changed rows (a trigger, an updated_at column, an outbox table), then have a background worker pick them up, call the embeddings API, retry failures and write the new vectors back. That's a sync pipeline. You skipped the second database to avoid exactly this, and now you're building it anyway, just inside Postgres.

Bug 2: search that ignores permissions

Your ticket list endpoint filters by customer. Of course it does:

SELECT id, title, status FROM tickets
WHERE customer_id = $1;

Then someone adds search a month later:

SELECT id, title FROM tickets
ORDER BY embedding <=> $1
LIMIT 5;

The result: customer A types "billing problem" and gets customer B's refund dispute.

One missing WHERE clause. Postgres row-level security can catch it, but only if your setup passes the current user to the database on every request. Some platforms do that for you. Plenty of hand-rolled backends don't, and most pgvector tutorials skip the topic.

How Graphite handles both

Graphite is the AI service in Nhost. It keeps embeddings in your Postgres table with pgvector, so this is still the "just use Postgres" setup. The difference is who does the boring parts.

Graphite's API is evolving, so check the Nhost docs for the current setup. The results below come from a test project in October 2026.

Fresh embeddings

You add a vector column to the table and point Graphite at it with one config call: which table, which columns to embed and which model to use. You also add a small trigger (the docs have an example) that marks a ticket as outdated when its title or body changes. Graphite picks up those rows on its next sync, calls the embeddings API and writes the new vectors back. The sync pipeline I described for stale embeddings still exists, but Graphite runs it, not you.

To test it, I edited one of user A's tickets. "Feature request: export to CSV" became "Charts invisible in dark mode." Then I searched for "graphs can't be seen with the dark theme."

This is a small demo: 36 tickets, two users, OpenAI's text-embedding-3-small. It shows the behavior, not performance at scale.

Right after the edit, the ticket ranked 5th. The title was new, but the embedding was still the old one. After the next sync, it ranked 1st.

Sync runs on a schedule, every 5 minutes in my project, which is plenty for support tickets. Apart from that one trigger, I didn't write any sync code.

Search that knows who's asking

Permissions in Nhost live on the table. Here's the rule for regular users:

{ "filter": { "customer_id": { "_eq": "X-Hasura-User-Id" } },
  "columns": ["id", "customer_id", "title", "body", "status", "created_at"] }

Graphite adds a search query to the GraphQL API:

query Search($query: String!) {
  graphiteSearchTickets(args: { query: $query, amount: 50 }, limit: 5) {
    id customer_id title
  }
}

That query goes through the same permission rule as everything else. I ran one search, "I can't log in to my account," three times:

#	Admin (no rules)	User A	User B
1	[B] Unable to sign in	Can't log in after update	Unable to sign in
2	[A] Can't log in after update	Locked out of my account	Google login stopped working
3	[A] Locked out of my account	Two-factor code not accepted	Logged out every few minutes
4	[A] Two-factor code not accepted	Login fails on mobile app	Password reset page shows error
5	[B] Google login stopped working	Reset link says it expired	Forgot password, no reset email

As admin, the top 5 mixes both customers. As A or B, every result belongs to the person asking. The rule is defined once, on the table, and search follows it like any other query. Nobody had to remember a WHERE clause in the search code.

When you should use a dedicated vector DB

Fair is fair. pgvector has limits.

Most 2026 write-ups I found put the comfortable range at around 10 million vectors for typical 768 to 1536 dimension embeddings. Your number will depend on dimensions, RAM and how much you filter. Above that you're tuning memory and indexes, or adding pgvectorscale. A dedicated vector DB starts making sense with:

Hundreds of millions or billions of vectors
Sub-20ms p99 latency targets at high query volume
Heavy re-embedding, which leaves Postgres with a lot of dead rows to vacuum
A search product with its own team and needs like multi-vector retrieval

None of that describes your app? Keep the vectors next to the data.

So, do you need Pinecone?

Probably not. You do need a plan for stale embeddings and permissions. You can build that plan yourself, or let Graphite handle it.

How are you keeping embeddings in sync with your data right now? Triggers, cron jobs, hoping for the best? Tell me in the comments.

Supabase vs Appwrite vs Nhost: I built two apps with Claude Code

Max S. — Wed, 21 Oct 2026 17:50:02 +0000

If you let Claude Code build an app on your backend and never mention security, where does it put the access rules? And does it get them right? I tried it by building two apps on Supabase, Appwrite and Nhost through their CLIs, with the same prompts on each.

The first is a small polling app with one tricky condition: nobody should be able to see how other users voted.

The second is a more complex app, an incident logger with file uploads, team membership and a server function.

Setup

Every run used the same setup:

Claude Code running Opus 5.5 on medium reasoning
A new session, an empty folder and an empty cloud project for every run
Everything ran against the cloud, with no local stack and no Docker
Email confirmation switched off on all three, so test accounts could sign in right away
No plugins, skills or notes from earlier work

Neither prompt mentions permissions, roles or backends. The main thing I watched was where each platform leads the agent to put the access rules when nobody tells it to. I also tracked how smoothly it worked with each platform, how often I had to step in, and how long each run took.

First app: a poll with a secret ballot

The first line of each prompt named the platform and the project. The rest was the same in all three:

Build a polling app.

Users sign up and log in with email and password. Different users log in from different browsers and share the same data.

Anyone logged in can create a poll with a question and a few options, and can vote once per poll.

Everyone sees the total votes for each option. Each user sees which option they voted for. Nobody can find out how another specific user voted.

Only the person who created a poll can delete it.

Keep it minimal, styling does not matter.

I thought the hardest part would be keeping each vote secret. If people can read the votes to count them, they can also see who voted for what. So the votes need to be hidden, and the totals need to come from somewhere else.

Poll app results

All three produced a working app with the access rules enforced in the data.

	Nhost	Supabase	Appwrite
Time	2:46	3:11	4:43
Cost	$0.56	$0.70	$1.00
Tokens read	705K	1.3M	1.7M
Mistakes it had to fix	1	2	3
Times it stopped to ask me something	0	0	0
Docs pages opened	0	0	0
Where the rules ended up	row rules in the database	row-level policies in the database	database closed, everything through a server function
What it handed back	a local page	a local page	a deployed site on a public URL

Nhost: fastest, but with an extra setup step

On Nhost, Claude Code finished in 2 minutes 46 seconds. It created three tables and a view, set the permissions, wrote the page, then ran a two-user test against the live project and reported each rule as passing.

Only the person who voted can see their own vote. In the dashboard, the rule for the user role is user_id _eq X-Hasura-User-Id, and the public and anonymous roles can't access the table at all. Update and delete are closed too, so nobody can change their vote.

The totals come from a separate view, poll_option_totals, which counts the votes without showing who cast them. Claude Code came up with this view by itself.

The only mistake was in the test script: Claude Code used single quotes in a GraphQL query, which GraphQL doesn't accept. It caught the error, fixed it, and the test passed. The schema and permissions worked on the first try.

There was one extra step before I started the clock. The CLI couldn't read the admin secret, so I had to get it from the dashboard and give it to the agent in the prompt.

Supabase: no questions, two wrong turns

Claude Code needed 3 minutes 11 seconds on Supabase and didn't ask me a single question. It applied the schema, tested it with two throwaway users, then deleted them.

Row-level security is on for all three tables, and every policy applies only to signed-in users (the authenticated role). The votes table has cast own vote for inserts and read own votes for reads. Polls have read polls and creator deletes poll, and options have read options. Anonymous visitors get no access.

Both of Claude Code's mistakes came from the CLI:

It used two flags together that the CLI doesn't allow. The error message explained the fix, and the next attempt worked.
The admin key it saved was incomplete. The Supabase CLI shows only part of a secret key unless you add a reveal flag, and it doesn't tell you the key is cut off. With a broken key, the test users were never created. The first error Claude Code saw was permission denied for function create_poll, so it spent two debugging steps looking for a permissions bug when the real problem was the key.

Claude Code also knew about a Supabase quirk: loading data inside the handler that runs when a user logs in or out can freeze the client. It delayed that call on purpose, though it only told me about it when I asked.

By default, Supabase doesn't turn on row-level security for new tables, and I left that setting alone. Claude Code turned it on by itself.

Appwrite: the slowest, with the database closed

Building on Appwrite took the longest, 4 minutes 43 seconds. That's because Claude Code did two extra things: it wrote a server function and deployed the app to a public URL without being asked.

The votes table has no permissions at all: the Security tab is empty, and row-level security is on. No user can read or write the table directly, signed in or not.

On Nhost and Supabase, a signed-in user's browser reads the votes table directly, and a permission rule filters what comes back. On Appwrite, the browser only talks to a server function that checks who's asking, which makes this the strictest setup of the three.

When I asked why it went this way, Claude Code explained that in Appwrite, client-side permissions can't stop someone from writing a vote with another person's ID. The platform doesn't check that the ID belongs to the user who created the row, so it moved every write to the server to block fake votes.

Along the way, it made three mistakes. The first two were small: it typed appwrite projects instead of project, and its first check of the SDK version failed. The third came after deploying. It grabbed the first URL the tool printed, but that turned out to be a private preview link that sends visitors to an Appwrite sign-in page. After that, it created a public domain and admitted that a real user would have run into that login page.

Polling app recap

On Nhost, Claude Code closed the votes table to everyone except the person who voted and added a view that returns only the counts.

The Supabase version has a policy that lets each user read only their own votes, plus a function with extra privileges that returns the totals.

Appwrite got the strictest setup: the table is closed to every user, and all reads and writes go through one server function.

Second app: a team incident logger

Each platform got a fresh project and this prompt:

Build a team incident logger.

Users sign up and log in with email and password.

Anyone logged in can create a team and invite other users to it by email address. A user can belong to several teams.

Incidents belong to a team. Anyone on that team can report one with a title, a description, and a severity of low, medium, high or critical, and can attach a .txt log file to it.

People on a team can see that team's incidents and open their attachments. People outside the team cannot see either, including the attached files.

Only the person who reported an incident can edit it, delete it, or mark it resolved.

When an incident is reported as critical, the platform itself should react to that and run a server function that records an alert was sent.

Keep it minimal, styling does not matter.

Compared to the polling app, the incident logger adds four things:

File storage. Files need their own permissions, separate from the incident records. A common leak is when the incident itself is locked down, but the attached file sits at a URL anyone can open.
Access based on team membership. In the polling app, the rule was "is this vote mine". Here it's "am I on the team this incident belongs to", so the check has to go through a third table with the team members.
A server function that the agent has to deploy to the platform.
A trigger. The function should run on its own when a critical incident shows up in the database, without the app calling it. Each platform does this differently.

The thing I wanted to check most was whether someone outside a team could open another team's attachment from a direct link.

Incident logger results

	Supabase	Appwrite	Nhost
Time	4:48	6:22	8:20
Cost	$1.25	$2.21	$2.64
Tokens read	1.0M	3.3M	5.0M
Mistakes it had to fix	2	2	1
Times it stopped to ask me something	0	0	0
Docs pages opened	0	0	several
Its own end-to-end checks	30	20	31
Where the file rule ended up	a policy on the storage path	row permissions granted to a team	a relationship chain in the database
What it handed back	a local page	a deployed site on a public URL	a local page

On the incident logger, Supabase was the fastest, Appwrite came second, and Nhost, which was the fastest on the polling app, came third.

Time and cost line up with how many tokens Claude Code read on each platform: 1M on Supabase, 3.3M on Appwrite and 5M on Nhost. The more the agent had to read to figure out a platform, the longer and more expensive the build got.

All three apps got the access rules right again. I checked the permissions in each project myself, so the code below is what's actually deployed.

Supabase: the fastest this time, with no questions asked

Claude Code got project access through my existing CLI login, applied the migration, deployed the Edge Function from the CLI and was done before I'd read half of its output.

To test the permission rules, it ran them inside a transaction that it rolled back at the end, so none of the test data was saved. Then, without being asked, it ran Supabase's security advisor and fixed two of the issues it found: a trigger function that could be called over RPC, and a function without a fixed search_path.

At the end, it told me to turn off email confirmation for testing. I had already done that, but Claude Code never checked the project's auth settings, and nothing in Supabase prompted it to.

The app has eight row-level policies across five tables, and all of them apply only to signed-in users. Members can read everything that belongs to their team and add incidents, and only the reporter can edit or delete one. The teams and team_invites tables have no write policies at all, because creating a team and inviting someone go through functions with elevated privileges.

For files, Claude Code stored each attachment in a folder named after the team's ID, and the read policy checks that folder against the user's teams:

bucket_id = 'incident-logs'
AND is_team_member(try_uuid(storage.foldername(name)[1]))

Only the reporter can upload or delete a file. For critical incidents, a database trigger calls the Edge Function through pg_net, and the shared secret is stored in Vault.

Appwrite: built-in teams and another unrequested deploy

As with the polling app, Claude Code put the app on Appwrite's hosting without being asked. This time it ran into a problem. Appwrite only lets an app connect to a project from domains added in the project settings, and Claude got an error while adding one.

It also left a setup.sh, but the script is just a list of the commands it ran and won't work on a fresh project. The first run of those commands failed halfway, because optional columns in Appwrite need an explicit flag.

Claude checked that someone outside a team can't list its incidents, open one by ID, view or download a file, or add an incident to that team. It didn't click through the finished app itself, because that would have created a real account on a live public site.

For teams, it used Appwrite's built-in Teams feature, which already handles invitations, membership and invite emails. On Nhost and Supabase, Claude had to build all of this by hand.

Each incident gives access to its own team, and at the table level, signed-in users can only create incidents. Appwrite combines table and row permissions with OR, so any read access on the table would let everyone see every incident, whatever the row says. Appwrite also won't let a user give access to a team they aren't in, so nobody can share an incident with someone else's team.

One limitation is that only the team's creator can invite people, because that's Appwrite's default for team owners. Letting every member invite would have needed a server function, and Claude pointed this out itself as something I might want to change.

The alert function is connected to Appwrite's database events, so Appwrite runs it whenever an incident is created or updated, with no extra code in between.

Nhost: file rules three relationships deep

By Claude's own count, about two-thirds of the run went into deployment and figuring out how Nhost works.

The Nhost CLI has no command that applies migrations and metadata to a cloud project. So Claude Code pushed the schema and metadata through Hasura's HTTP API instead. It also created the migration-tracking table by hand and added a row to it, so the later deploy wouldn't run the same migration a second time.

Then it found that nhost init leaves the metadata folder empty, but a deploy applies whatever is in that folder. To avoid wiping the built-in auth and storage tables, Claude wrote out metadata for every table, including those.

Functions on Nhost deploy only from a connected GitHub repo, so the alert function stayed untested until Claude did a full push and deploy near the end.

The app has five tables, and everything below comes from the deployed metadata. A user can read a file if they uploaded it, or if it's attached to an incident from one of their teams. To check the second part, the rule goes from the file to the incident, then to the team, then to the team's members:

_or:
- uploaded_by_user_id: {_eq: X-Hasura-User-Id}
- incidents: {team: {members: {user_id: {_eq: X-Hasura-User-Id}}}}

Uploads are checked by bucket, file name and MIME type, so a binary file renamed to .txt still gets rejected. The uploader's ID comes from the user's token, so the app can't fake it. Only the reporter can edit an incident, and a separate check stops anyone from attaching a file someone else uploaded.

For critical incidents, Claude set up a Hasura event trigger. It fires when an incident is created, and on updates only when the severity changes. It retries three times and sends a shared secret in the header.

Testing file access myself

File access was the main thing I wanted to test, so I checked it by hand on each platform. I made an account, created a team, reported an incident with a .txt attached, and then tried to open that file three ways: signed out, signed in as someone outside the team, and signed in as a team member.

On all three platforms, only the team member could open the file. The difference was in how each platform handled the link.

Appwrite is the only one where an attachment has a URL you could paste into a chat. The login session is stored in a browser cookie, so the same link works differently depending on who opens it: a team member gets the file, and everyone else gets a 404.

Supabase and Nhost don't give you a link at all. The app downloads the file through the SDK and attaches the user's token to the request, so there's nothing to copy and send to someone. If you open the storage URL directly in the browser, you get an error even as a team member, because the browser doesn't send that token.

Here's what each one returns to an anonymous request:

	Anonymous request to the file
Appwrite	`The requested file could not be found`
Supabase	`Bucket not found`
Nhost	`you are not authorized`

Appwrite and Supabase respond as if the file doesn't exist, while Nhost says you aren't authorized. Later, when I asked Claude about common pitfalls on Appwrite, it named this exact behavior as something that makes debugging harder.

Claude almost never opened the docs

In five of the six runs, Claude Code didn't open a single documentation page. It got what it needed from the CLI's --help output and the type definitions in the installed SDK. On Supabase, the help text is how it found the --reveal flag for the cut-off admin key, and later the --use-api flag that let it deploy a function without Deno installed. On Appwrite, it used --help, npm view to check SDK versions, and the error messages themselves.

The only exception was Nhost on the incident logger. Before writing anything, Claude read the Nhost docs on functions, event triggers and storage permissions. My guess is it didn't know those parts of Nhost well enough from training.

What's easy to get wrong on each platform

When I asked afterward what's easy to get wrong about permissions on each platform, Claude gave the same answer every time: showing vote totals without revealing who voted for what.

The Nhost agent explained it best. Permissions there work row by row, so letting everyone read the votes table to count votes also lets them read who cast each one. Its fix was a separate view. As it put it, you have to come up with that yourself, because it's not the obvious first move.

Supabase's fix was a function running with elevated privileges, and Claude warned that writing that function carelessly leaks exactly what you were protecting. For Appwrite, it pointed out that table and row permissions are combined with OR, so unless the table grants no read at all, row-level privacy silently does nothing.

What they knew was wrong with their own work

I also asked each one where its own work was most likely to be broken in a way its tests wouldn't catch. All three came back with long lists.

The worst was Supabase's. Invites there are applied the moment the user row is created, which is before the email address has been confirmed. That's fine as long as confirmation is on, since an unconfirmed account can't log in. But on Supabase, Claude was the one that told me to turn confirmation off for testing. Do that, and anyone who guesses an invited address can sign up with it and land inside that team, incidents and files included. The agent's own advice: until that's fixed, don't turn confirmation off.

On Nhost, Claude ran into a smaller invite problem, but caught it while building. Its invite trigger ran before the permission check, so someone outside a team could use invites to test whether an email had an account. It added a membership check and reran its tests. Supabase's build has this hole too, and Claude mentioned it there only when I asked.

Other problems Claude listed, none of which its tests covered:

"Only .txt" is weaker than it sounds on Supabase and Appwrite. Both check the file extension and the content type the browser declares, so neither looks at what's actually in the file. Nhost detects the type from the file's contents, which is why a renamed binary gets refused there.
Alerts can vanish silently. Supabase's pg_net call fires once with no retry; if the function is down, nothing is recorded and nothing says so. Nhost retries three times and then gives up just as quietly.
Orphaned files. On Supabase and Appwrite, a failure between uploading a file and saving the incident leaves the file in storage with nothing pointing at it, and in one case nobody can delete it.
Membership changes. On all three, someone removed from a team keeps edit rights on incidents they reported. None of them built a way to remove a member, so it doesn't come up yet.
Weak assertions in their own tests. On Appwrite, Claude admitted that any 404 counted as "access denied" in its suite, so a typo in an ID would have passed too, and that its "no alert for a low-severity incident" check simply waited six seconds.

What the rules cost

Then I asked how the file permission check would hold up as data grows. The answers varied a lot in how honest they were.

The Supabase answer was the most specific and the most self-critical. Opening one file is two indexed lookups. Listing them is where it degrades: the membership check is a function Postgres can't fold into the query, so it runs once per row, and try_uuid opens a mini-transaction on every call. It offered a cheaper pattern the planner could evaluate once per query, then said plainly that it had run no EXPLAIN, no load test and no volume test.

For Appwrite, Claude noted that each team a user joins lengthens the list of roles checked on every query, that the app stops at a hundred incidents with no paging beyond that, and that viewing an attachment costs an extra rate-limited request. It added an index and measured nothing.

On Nhost, Claude added indexes on the columns its file permission rule checks, and said it couldn't measure anything without direct database access.

What I took away from this

Going in, I was pretty sure all three backends would handle both apps. They did, though getting there was a lot rougher on some than others.

Claude Code worked very differently on each platform, and I think most of that comes down to how well it already knows each one, which also varies by task.

One visit to the docs across six builds still surprises me. Everything else came from the CLI's help text, the SDK's types, and whatever the model already knew. If that's how people are building now, then help output and type definitions are doing work most teams think their documentation site is doing.

The other thing I noticed is that Claude kept most of the risks to itself until I asked. On all three platforms, it had a list ready about where its own work might break, and almost none of it came up on its own.

Both of these are still small apps. What happens on something real, with a schema that keeps changing and features piling up, is another question. That's the next test.

Supabase Alternatives in 2026

Max S. — Mon, 15 Jun 2026 09:26:09 +0000

Disclaimer: Supabase is a great platform, with by far the largest ecosystem and community.

However, if you're looking to leave, the reasons usually come down to three things:

The pricing gets non-linear at the exact moment a project starts working
PostgREST doesn't scale gracefully to complex relational frontends
You have requirements (self-hosting mandates, a reactive data model, compliance regimes, or AI agent workflows) that the platform doesn't model well

If none of that is your situation, stop reading.

What follows is Nhost, Neon, Appwrite, Convex, Firebase, PocketBase. Not Railway, not Render. Those are infra platforms and comparing them to Supabase doesn't make sense, like comparing a toolbox to a hammer.

Nhost

Nhost is, structurally, very similar to Supabase: Postgres, auth, storage, serverless functions. The difference is the API layer. GraphQL instead of PostgREST, powered by Constellation, their own open-source GraphQL engine written in Go.

If you have a dashboard that needs data from six related tables, a GraphQL query gives you exactly that in one round trip. PostgREST gives you a series of choices: chain multiple requests, write RPC functions that fake the join, or start questioning your data model. It gets unwieldy fast.

The permission system compounds this: role-based row and column access is defined inside the query engine itself, so you're not maintaining separate RLS policies in SQL that drift from your actual auth logic.

Nhost fits naturally for AI agent workflows. Agents touching shared Postgres state get real-time updates via subscriptions, and the permission model means no separate access control layer bolted around your database calls.

Neon

Neon is not a full Supabase replacement. It's a database. That's it. No auth, no storage, no functions, no realtime. If you pick Neon, you're assembling the rest of the backend yourself.

Why would you do that? Because what Neon actually built is genuinely impressive: they separated compute from storage at the Postgres level, which makes database branching possible. A full copy-on-write snapshot of your database in seconds. One branch per pull request, against real data, gone when the PR closes. Databricks acquired them last year and it's continued to develop. It's become the thing other providers benchmark against.

Neon is a good fit if the database itself is your unsolved problem and the rest of your infrastructure is already handled: platforms provisioning a database per customer, CI pipelines that need isolated environments per test suite, teams with existing auth that just want better Postgres without ripping everything else out.

Appwrite

The thing Appwrite does well, genuinely well in a way the other platforms kind of half-ass, is self-hosting. One docker-compose command and you have a full working stack. Not "full working stack but you need to configure eight more things." Actually full, actually working.

This matters more than people give it credit for. Air-gapped environments, healthcare compliance, regions where AWS and GCP are politically complicated, enterprise contracts with data residency clauses that say the words "within the EU" in boldface. Appwrite handles all of this without treating self-hosting as a community project that the founders are vaguely embarrassed by.

Here's the catch, and it's a real one: Appwrite is not Postgres. The data layer is its own collection and document model. Which means no SQL, no pg_dump, no EXPLAIN ANALYZE when a query gets slow, no connecting a BI tool to it. One of the quiet reasons Postgres-backed platforms feel safe is that the escape hatches are all there if you need them. Appwrite closes most of them.

If your team thinks in SQL, you'll notice this within the first week. There's no workaround for it.

If you're building something mobile-first, especially on Flutter, Appwrite's Flutter SDK is one of the best in this space and the SQL thing might genuinely not matter. Different problem, different tradeoffs.

Convex

Almost every comparison article gets Convex wrong, usually by fitting it into a row in a feature table next to Firebase and calling it a document database alternative. It's not that.

The actual model: your backend is TypeScript functions. The data layer is document-relational. The important part, the part that sounds like a detail but isn't, is that queries are reactive subscriptions by default. When data changes, every subscribed client updates. Automatically. Without you writing cache invalidation logic. Without you managing subscription channels. Without you thinking about whether two parts of the UI are looking at stale data from the same table.

End-to-end TypeScript from the schema to the React component means the types aren't generated artifacts you have to remember to regenerate. They're the same code.

When does this matter? Collaborative editors. Live multiplayer state. AI agent applications where multiple processes are writing to shared state concurrently and the UI has to reflect it immediately. Convex makes a whole class of synchronization bugs structurally impossible. Not hard to write — the runtime doesn't let them exist.

When does it not matter? Analytical stuff. Reporting. Anything that needs direct SQL access. Convex's document model won't bend to accommodate an ad-hoc GROUP BY.

The learning curve is also real: the first two weeks are genuinely disorienting. The mental model is different enough from "database + API" that your existing instincts are wrong in subtle ways. Developers who get through that describe the next few months as feeling like they have superpowers. I believe both descriptions. Whether the trade is worth it depends on whether realtime consistency is your actual hard problem.

Firebase

Hard to imagine cases when people move from Supabase to Firebase, but I can't skip this.

If you outgrow Supabase or Nhost and need to leave, your data is Postgres. You run pg_dump, you load it somewhere else, you update your connection strings. It's a project, not a crisis.

If you outgrow Firestore, you're transforming a data model, not migrating rows. The access patterns you built around Firestore's model (the denormalization, the collection structure, the places where you stuffed data into subcollections to avoid a join) don't translate. It's months of work under pressure, usually when the thing that forced the move isn't waiting for you.

That's not a dealbreaker for the right use cases. Offline-first mobile sync where the app needs to work through genuinely unreliable networks and reconcile cleanly when connectivity returns: Firebase is still the best answer here, and it's not close. Simple read-heavy access patterns at scale without relational complexity. Google ecosystem products where auth, analytics, and ML are already in Cloud.

PocketBase

I'll just say it: PocketBase is one of my favorite pieces of software that exists right now.

It's one Go binary. SQLite, realtime subscriptions, auth, file storage, admin UI. Runs on a $5 VPS. ~60k GitHub stars. One maintainer.

That last part is both the appeal and the risk. The total system fits in one person's head, which means deployment is copying a file, the admin UI is actually good, and there are no abstractions hiding from you. For internal tools, admin panels, side projects, prototypes, hobby things that are more complex than a static site: PocketBase is more elegantly suited to these than anything else on this list by a significant margin.

The ceiling is real too. SQLite means single node. There's no path to horizontal scaling, no managed hosting tier for when self-managing gets annoying. There was a meaningful auth-bypass CVE earlier this year, patched quickly and responsibly disclosed, handled well by the maintainer. But "handled well by a single person" is a different risk profile than "handled by a security team at a funded company," and that's a real input to a production decision depending on what you're building.

The failure mode I've watched happen: someone uses PocketBase as a placeholder while the project proves out, then migrates to something "real" after it does. That migration always happens under deadline, always takes longer than anyone estimated, and is always more painful than if they'd made the decision upfront. Better to either commit to it for what it actually is (a complete backend for things that fit on one node, which is honestly a bigger category than people admit) or pick something else from the start.

So How Do You Actually Pick

Start with the data model. This is the decision that matters most and people skip over it to compare pricing tiers instead.

If you need GraphQL, a strong permission layer, or your backend will serve AI agents: Nhost. If you want the most mature REST-based Postgres BaaS with the largest ecosystem: go back to Supabase. If the database is your only unsolved problem and everything else is handled: Neon.

Document-shaped data with stable, simple access patterns: Firebase or Appwrite.

Then self-hosting. If it's a hard requirement, not a nice-to-have: Appwrite or PocketBase. Self-hosted Supabase exists but the full service stack is a real ops commitment. Not a one-afternoon project.

Then realtime. If live synchronization is the core mechanic of what you're building and not just a feature checkbox, actually evaluate Convex. Don't just put it in the table and move on.

Before you commit to anything: run your actual schema through the top two options. Real tables, real auth flow, real queries from the app. Not a tutorial, not a hello world. The places where something breaks or needs a workaround are the information you need, and you won't get it from any comparison article including this one.

We Built an Open-Source GraphQL Engine to Replace Hasura

Max S. — Thu, 04 Jun 2026 15:13:37 +0000

TL;DR

We built Constellation — an open-source GraphQL engine written in Go that is a near drop-in replacement for Hasura Community Edition. It reads the same metadata, generates the same schema, and serves the same GraphQL API. In production it uses ~90% less memory than Hasura with comparable or better latency, before any dedicated performance work.

If you run Hasura today, this post is for you. If you build GraphQL infrastructure, care about open-source sustainability, or just want to see real production memory numbers from a fresh Go rewrite — keep reading.

The problem with depending on someone else's engine

Hasura v2 has been the backbone of Nhost's GraphQL layer for years. It's a genuinely good piece of engineering, and we built a lot on top of it.

But three things changed:

Hasura v2 is winding down. Development has shifted to Hasura v3, which takes a different approach to open source — the engine core is Apache-licensed, but the CLI, web console, and developer tooling are proprietary. That's a meaningful shift from v2, where the full stack was open. Continuing to depend on an engine that's winding down toward end-of-life, or migrating our GraphQL and permissions layer to one where the tooling is closed, weren't paths we were willing to take.

Memory was consistently our heaviest service per project. A GraphQL engine sits between every client request and your database. It should be fast and lean. Instead, it was the most expensive thing we ran per project — and memory in particular is hard to throttle gracefully under load.

We didn't own a critical piece of our infrastructure. The API and permissions layer sits at the center of every Nhost application. When something goes wrong, or when you want to ship something new, depending on someone else's roadmap is expensive in ways that don't show up in dashboards.

So we built our own — while keeping full compatibility with Hasura on the GraphQL request path.

What Constellation actually is

Constellation is a GraphQL engine that turns a relational database into a role-based GraphQL API. It is designed to be a near drop-in replacement for Hasura Community Edition.

Concretely, that means:

Same metadata format. It reads your existing Hasura metadata — either from a YAML/JSON file on disk, or straight from Hasura's hdb_catalog.hdb_metadata table.
Same generated schema. Same types, same relationships, same permission-aware shape per role. We verify this with byte-level schema diffs (more on that below).
Same request surface. Queries, mutations, and subscriptions over the same /v1/graphql endpoint, plus remote schemas and cross-source remote relationships.

It's a fresh Go codebase — not a fork of Hasura. PostgreSQL and SQLite are first-class backends today. The connector design is built so additional databases can plug in without touching the query planner.

Where Hasura's behavior is surprising or outright wrong, we occasionally diverge — and every such divergence is documented in KNOWN_DIFFERENCES.md. Correctness over surface area is one of our explicit goals.

The numbers that made us ship it

We ran Constellation against real production workloads, side by side with Hasura, on the same database and the same traffic. We didn't tune anything special for these results.

Memory

Constellation's memory usage sits ~90% below Hasura's serving the same traffic. In absolute numbers: Hasura at ~180 MiB, Constellation at ~15 MiB. This is not a benchmark environment — these are production dashboards.

A note on the CPU panel in that chart: Constellation's CPU looks dramatically lower, but we're talking millicpus here. Both engines are cheap on CPU in absolute terms; the gap is real but small. Memory is where the meaningful difference lives.

Latency

Across the same window, Constellation also serves requests a little faster.

Request latency over the same period: Hasura (blue) regularly spikes toward 60–80 ms, while Constellation (purple) mostly stays under 40 ms.

To make the comparison concrete, here's the per-period delta of Constellation minus Hasura for the same traffic. Anything in the green region (below zero) means Constellation was faster; the occasional red spike above the line marks the moments it wasn't.

Latency delta (Constellation minus Hasura). Most of the line sits in the green, below-zero region, meaning Constellation was faster, with a handful of red spikes where it briefly wasn't.

These are raw production dashboards, not a curated benchmark. That's rather the point. We didn't tune anything special to get here.

How it works alongside Hasura (not instead of it — yet)

Constellation doesn't yet implement Hasura's metadata HTTP API (POST /v1/metadata). It consumes metadata but doesn't author it. So the current deployment model is straightforward:

Hasura owns metadata authoring. Constellation owns request serving. Both point at the same database.

In practice, an Nhost project running Constellation gets two endpoints:

https://<subdomain>.hasura.<region>.nhost.run → Hasura (metadata authoring, plus anything Constellation doesn't serve yet)
https://<subdomain>.graphql.<region>.nhost.run → Constellation

The key property: you can flip Constellation on, run real traffic through it, and remove it at any time to fall back to Hasura with zero migration. That's the whole appeal of the side-by-side model.

Once Constellation supports metadata mutations on its own, the Hasura half can be dropped entirely.

What's solid vs. what's missing

Constellation is alpha. That label reflects feature coverage against Hasura — not the stability of what's already there.

Solid and in production:

✅ PostgreSQL and SQLite connectors
✅ Full GraphQL query, mutation, and subscription pipeline
✅ JWT and admin-secret auth
✅ Role-based permissions
✅ Remote schemas
✅ Cross-source remote relationships

Not yet implemented:

❌ Hasura Actions
❌ Event and cron triggers
❌ REST endpoints
❌ Allowlists and query collections
❌ Inherited roles, native queries, computed fields
❌ MSSQL, BigQuery, Snowflake backends

If your app lives mostly in the query/mutation/subscription world, there's a good chance Constellation already does what you need. If you lean heavily on Actions or event triggers, keep those on Hasura for now.

What's next — and how you can shape it

The near-term roadmap is focused on closing the gap: implementing the metadata HTTP API so Constellation can own the full stack without Hasura running alongside it, expanding the feature surface into Actions and triggers, and eventually supporting additional database backends.

But the most valuable thing right now isn't what's on our roadmap. It's real-world usage.

There are four concrete ways you can help:

Run real traffic through it. Enable Constellation next to your existing Hasura instance (see below) and point production traffic at it. That's the fastest way to find real divergences and edge cases.
Report schema diffs. If nhost schema diff turns up a divergence that isn't covered in KNOWN_DIFFERENCES.md, open an issue with the diff hunk and a minimal metadata snippet. That's how new issues get documented — or fixed.
Report runtime bugs. A query that returns different results, a subscription that misbehaves, a permission that doesn't line up — under live traffic these are the most valuable reports we can get.
Read the code and contribute. It's open source and we've worked hard to make it approachable — small interfaces, golden-file tests, and per-package documentation. PRs and questions are welcome.

Try it yourself

The lowest-friction path is enabling Constellation on any Nhost project. Add one block to nhost/nhost.toml:

[experimental.constellation]
version = "0.4.0"

Pick the latest tag from CHANGELOG.md. With that in place, your project runs both engines. Remove the block and you're back to Hasura.

To verify Constellation generates the same schema as Hasura for each role:

nhost schema dump --role user \
  -u "https://<subdomain>.hasura.<region>.nhost.run/v1/graphql" \
  -o schema.hasura.user.graphqls

nhost schema dump --role user \
  -u "https://<subdomain>.graphql.<region>.nhost.run/v1/graphql" \
  -o schema.constellation.user.graphqls

nhost schema diff -a schema.hasura.user.graphqls -b schema.constellation.user.graphqls

An empty diff means Constellation produced a byte-equivalent schema for that role. Any non-empty diff should map to a known difference — and if it doesn't, that's exactly the kind of issue we want to hear about.

Prefer to run it standalone without an Nhost project? The repository README has full build and run instructions.