Supabase for AI Agents: Memory and Vector Search

An agent needs memory outside itself: the model remembers nothing between calls, and context runs out sooner than expected. Supabase covers that without separate infrastructure.

Storing agent state

Three things that must live in the database:

What has been done. The basis of idempotency. After a restart the agent must learn the email was already sent rather than send a second one. Without that, reruns create duplicate effects - see idempotent pipelines.

Results. Extracted facts, decisions made, objects created. Keeping them only in the conversation means losing them at the first context compaction.

Step logs. What went in, which tool was called, what came back. Incident analysis is impossible without them: you see the outcome and not why it is that outcome.

A practical detail: logs grow fast. Set a retention limit immediately, or they become the largest table in the database.

The long version on what agents remember: AI agent memory.

Vector search

The problem: finding what is relevant among many things when there is no exact word match. The user asks in their own words while the documents use different ones.

How it works: text is turned into a set of numbers reflecting meaning, and search runs by proximity between those sets. Texts about similar things end up near each other even with different wording.

In PostgreSQL this is done with a vector extension: no separate system is required. The practical advantages:

• Data and vectors together. No two stores to keep in sync.
• Ordinary filters work. You can search for similar documents belonging to one user, which is harder in a dedicated vector engine.
• Access rules work. The same policies as on other tables - see authentication and RLS.

When a dedicated engine is needed: at large volumes and high query rates. For an MVP or internal tooling that is premature.

What to account for in practice:

An index is mandatory. Without one, search scans the whole table and becomes unacceptably slow at tens of thousands of rows.

Chunk size. Chunks that are too large give vague results; too small and they lose context. Tune it empirically on your data.

Hybrid search. Combining vector search with ordinary text search usually beats either alone.

Changing the embedding model breaks the index. Vectors from different models are not comparable. Changing model means recomputing everything.

What belongs in the database and what does not

In the database:

• State and completion markers.
• Extracted facts and results.
• Vectors and documents for search.
• Step logs with limited retention.
• Metrics: step counts, cost, failure rate.

Not in the database:

• Whole raw model responses. Large and almost never reused.
• The full context of every step. The same.
• Secrets. Model and third-party keys belong in function environment variables, not in tables.
• Personal data you do not need. If it can be avoided, avoid it.

Common mistakes

1. No repeat check. The agent restarted and performed the action twice.
2. No index on vectors. Fine at a hundred rows, stalls at ten thousand.
3. Logs with no retention limit. Within a month they outweigh the data.
4. The service key in the client. An agent running in a browser with full database access is an open database.
5. Re-embedding on every query. Document vectors are computed once at load time, not on every search.

The general theory is in the AI agents guide. The tool overview is in the Supabase guide.