Buda agents connect to a Supabase development project, never production, through Supabase’s official MCP server. Agents can inspect schema, read logs, check advisors, and draft migrations — with read-only mode and project scoping available from the first connection.
Most database work is not writing SQL. It is working out what the schema already looks like, why a query got slow, and what a migration will break before you run it.
This integration scopes agents to a development project: through Supabase’s hosted MCP server they list tables, read logs, pull advisors, and draft migrations a developer reviews. Agents can list tables and extensions, read API, Postgres, and Edge Function logs, pull security and performance advisors, generate TypeScript types, and draft migrations for a developer to review.
Your data never leaves Supabase; what Buda adds is somewhere the investigation happens before the change.
A chatbot reasons about the schema you paste into it, which is usually out of date by the time you paste it. A Supabase-connected agent can list the tables itself, read the migration history, check what the advisors are already warning about, and pull the logs from the failure you are describing.
Instead of assembling context by hand before every debugging session, you can ask:
List the tables involved in checkout, read the Postgres logs from the last hour, check the performance advisors, and tell me why these queries got slow.
The agent retrieves the schema, the logs, and the advisor output, then explains what it found and what it would change.
Your data stays in Supabase. Buda is the workspace where that context is combined with your code and turned into a change a developer approves.
Supabase’s MCP server groups tools into feature groups, all enabled by default except Storage.
Buda agents can retrieve supported information including:
Where the connection is not in read-only mode, agents can call tools including:
Several of these are destructive by design. Supabase’s own documentation is direct about the boundary: the MCP server is intended for development and testing, not production data. Branching tools are labeled experimental and require a paid plan, and the Storage group is disabled by default. Access runs under the authenticating developer’s own Supabase permissions.
The useful work here is not writing the migration. It is everything you have to understand before the migration is safe to write.
New codebases come with databases nobody documented.
The value is the risk assessment, not the DDL.
Example workflowAdvisors accumulate faster than teams read them.
Function failures need logs and source read together.
RLS gaps are quiet until they are not.
Type drift causes bugs that look like application bugs.
Four patterns, all scoped to development projects and ending at a developer’s review.
Trigger: A developer joins the project.
Buda agent workflowTrigger: A migration is proposed.
Buda agent workflowTrigger: Run every Monday.
Buda agent workflowTrigger: An error rate spike is reported.
Buda agent workflowRun any of these against a connected Buda agent on a development project, never production.
List every table in this project with its columns and foreign keys, then explain how the ordering and payments tables relate to each other.
Read the Postgres logs from the last two hours, check the performance advisors, and tell me which queries are slow and why.
Here is a migration adding a NOT NULL column to the orders table. Check the current data and tell me what would fail, plus what the rollback would be.
List tables without row-level security enabled, and for tables that have policies, show me any that are broader than they look.
The checkout Edge Function is throwing errors. Read its logs and source and tell me what is failing.
Generate TypeScript types from the current schema and tell me where they differ from the types committed in our repo.
A migration script is the right tool when you already know exactly what to change.
For example:
Add an index on orders.created_at and deploy it through the normal pipeline.
An MCP-connected agent earns its place before that point, when the question is what should change and what it will cost.
These three queries got slower after last week’s release. Work out which schema change caused it and what the safest fix would be.
| Capability | Migration Scripts and CLI | Buda Supabase MCP Integration |
|---|---|---|
| Deterministic, versioned changes | Strong | Supported as the output of the workflow |
| Natural-language instructions | Not applicable | Yes |
| Reading logs and schema together | Manual correlation | Agent retrieves both |
| Judging risk before applying | Depends on the author | Agent inspects live schema and data shape |
| Working through advisor findings | Manual | Agent can rank by real exposure |
| Cross-tool context | Requires separate tooling | Combines with other Buda tools |
| Explaining a diagnosis | Not applicable | Yes, citing logs and schema |
| Draft-first changes | Depends on process | Natural agent pattern |
| Enforced read-only option | Not applicable | Read-only mode on the connection |
For example:
Use migrations and CLI for the change itself. Use a Buda agent for the investigation that decides what the change should be.
A schema change usually starts somewhere other than the database.
The requirement came from a spec, the bug arrived through support, the code lives in a repository, and the deploy that exposed it happened on your hosting platform. An agent that reads them together can trace a symptom back to its cause upstream.
Line up a migration in the repository against the branch it targets, before anyone applies it.
Correlate a database error window with the deployment that preceded it.
Attach schema findings to the issue tracking the work, with the evidence included.
Turn an incident conversation into a log-backed explanation instead of a guess.
Compare the documented data model against the schema that actually exists.
Following the symptom upstream is how a database error gets attributed to the change that caused it.
Supabase is unusually explicit about how its MCP server should be used, and this integration follows that guidance rather than working around it.
Supabase’s documentation states plainly: do not connect the MCP server to production data; it is designed for development and testing. It also advises against giving it to customers or end users, since the server operates with your developer permissions.
The connection supports enforced boundaries rather than policy ones. Setting read_only=true executes all queries as a read-only Postgres user. Setting project_ref scopes the connection to a single project and disables account-level tools. The features parameter limits which tool groups are available at all. Supabase also recommends using development branches for testing changes.
On prompt injection, Supabase is candid: the server wraps SQL results with instructions discouraging the model from following commands found in data, but states this is not foolproof and that you should review output before acting on it. Buda’s review model exists for exactly this reason.
An agent that can execute arbitrary SQL is useful and dangerous in the same breath. The value is in what it works out; the risk is in what it runs.
Buda is designed around it, with agents inspecting and drafting while a developer is the one who applies anything.
An agent is strong at the investigation: inspecting, reading logs, diagnosing, comparing, and drafting.
People should keep approving anything involving:
The teams that gain most are the ones where understanding the database costs more time than changing it.
Get schema, logs, and advisors assembled before debugging rather than during it.
Assess migration risk against the data that actually exists, not the data you remember.
Work through advisor findings ranked by real exposure instead of by severity label.
Correlate database symptoms with deployments and application logs in one pass.
Understand an inherited or fast-grown schema without a week of archaeology.
See where schema debt and unaddressed advisories are concentrated.
It is a connection that lets another application work with a Supabase project — inspecting schema, reading logs, and calling project operations with a developer’s own access.
Through Supabase’s hosted MCP server, pointed at a development project. Connection parameters control read-only mode, project scope, and which tool groups are active.
It means the agent reaches your Supabase project over the Model Context Protocol, turning a described debugging task into the right schema and log calls.
Supabase’s documentation says not to. It states the MCP server is designed for development and testing purposes and advises against connecting it to production data. This integration is built around that boundary.
Yes. Setting read_only=true on the connection executes all queries as a read-only Postgres user. Combined with project scoping and feature groups, this is an enforced limit rather than an instruction.
A Buda agent can list tables, extensions, and migrations, read logs across services, retrieve security and performance advisors, generate types, inspect Edge Functions, and — on a write connection — execute SQL, apply migrations, deploy functions, and manage branches.
The connection authenticates through OAuth and runs with the authenticating developer’s own Supabase permissions. Supabase notes this is why the connection should not be handed to customers or end users.
Supabase wraps SQL results with instructions discouraging the model from following commands found in data, and states plainly that this is not foolproof. Reviewing output before acting on it is part of the intended workflow, not an optional extra.
No. You describe the task in natural language. Safe use still requires deciding read versus write, which project to scope, and which feature groups to enable.
No. Buda sits alongside it, using project context for diagnosis and change preparation a developer applies.
No. The Supabase AI Assistant works inside the Supabase dashboard. Buda sits outside Supabase, putting project context to work in diagnosis and change preparation a developer is the one to apply.
Only on a development project, and preferably not at all until you have watched what it proposes. Start read-only and project-scoped, and keep applying changes a human action.
Most database incidents are not caused by a hard migration. They are caused by a straightforward one written without a full picture of what was already there.
Connect a Supabase development project to Buda and let agents assemble that picture — schema, logs, advisors, and history — so the person writing the change knows what it will cost.