Connect a Supabase Database to Your Agent

Connect a Supabase Database to Your Agent

Supabase is hosted Postgres. Connecting a project gives your agent its own schema inside it. The agent works with that schema in SQL: you describe the data you need and it creates the tables, and from then on every conversation with the agent can read and write rows. Only your own conversations can change the structure.

The project stays yours. Data, billing and the Supabase dashboard are all under your account. Mutiro holds no copy of it.

The Supabase connection is currently enabled per account. Contact us to turn it on for yours.

Connect

  1. Open your agent, go to Connections, and click Connect on the Supabase card.
  2. Authorize Mutiro in the Supabase page that opens and pick the organization that holds your project.
  3. Back in Mutiro, select a project from the list, or create a new one. Creating a project happens in your Supabase organization and follows its plan.
  4. Restart the agent. The card shows the project and the agent's schema name, which looks like mutiro_3f9a....

Build the data by talking

In your own conversation, tell the agent what you want to keep track of:

I run a small clinic. Keep patients and their appointments, with a status for each appointment.

The agent creates the tables in its schema and tells you what it made. Ask it to show the tables, add a column, or drop something it got wrong. Then describe how the data should be used in the agent's instructions or a skill, and share the agent.

People you share with can add, look up and change rows. They cannot alter tables: that tool is not present in their conversations, and the database role they run under refuses schema changes.

Who can change what

Users never touch the database. Nobody gets a login or a connection string. Every read and write goes through the agent, under a role you control.

The rule that matters: the database is the enforcement, instructions are the behavior. An instruction like "never delete a patient, archive instead" shapes what the agent does on a normal day, and the agent can refuse, ask, or explain. It is not a guard. A user who wants to get around it can, given enough persistence, talk the agent into it. The one thing nobody can talk the agent into is a permission its database role does not have.

So for anything that must hold no matter what is said, put it in Postgres:

  • Read-only where nothing should change: grant SELECT alone and the agent cannot write that table for anyone.
  • Constraints and triggers for what a row may look like and which transitions are allowed.
  • Views that expose only the columns or rows an app should see, with grants on the view instead of the table.

The agent cannot change the structure, so those lines stay where you put them. Use instructions for how the agent should behave, and the database for what it is allowed to do.

This fits shared data for a defined group: a clinic's schedule, a team's task board, a course roster. Everyone you share with is meant to see the same data. Per-user isolation, where each person sees only their own rows, is the next step.

Give the agent access to tables you already have

The agent's schema is separate from your application's tables. To let it use existing tables, grant its data role access from the Supabase SQL editor. The role name is the schema name on the connection card followed by _data.

Read and write on everything in public, including tables created later:

GRANT USAGE ON SCHEMA public TO "mutiro_<hash>_data"; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO "mutiro_<hash>_data"; GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO "mutiro_<hash>_data"; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "mutiro_<hash>_data"; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT USAGE, SELECT ON SEQUENCES TO "mutiro_<hash>_data";

For read only, grant SELECT alone. For one table, name it instead of ALL TABLES. Grants apply immediately, no restart needed. REVOKE with the same shape takes access back.

Two things to know before granting:

  • A grant means all rows. The agent's role does not follow your row-level security policies. Anyone who can talk to the agent can reach every row in a granted table.
  • Rows only. The agent can never create, alter or drop tables outside its own schema, whatever you grant.

Disconnect

Disconnect on the card removes the agent's database roles and Mutiro's authorization. The schema and its data stay in your project. Connecting the same agent to the same project again picks them up where they were.