Can it run SQL against my production database?

Yes — the connector reaches whatever your Neon account reaches, and that includes main. We would not tell you to rely on politely-worded instructions to prevent it. Say “on a branch” in the brief, and treat applying anything to main as a step you take, not one you delegate.

What does branching actually buy me here?

A branch is a copy-on-write copy of your data, so it comes up in seconds and holds the real rows rather than a thin fixture. That matters for the jobs worth handing over: a migration that passes against an empty schema tells you nothing, and a query plan is only honest against realistic data. When the agent is done you delete the branch and nothing it did survives.

Does it see my data, or only the schema?

It sees whatever its queries return, so on a database holding customer records a broad SELECT puts those records in the conversation. If that is your situation, the same branching answer applies for a different reason: work on a branch you have anonymised, or keep the agent to schema and plan questions where it never needs to read a row.

Developer tools

Neon + Burrak AI

Let an agent touch the database on a branch, not on production.

Connects with OAuth — revoke any time

Most of the useful things you would ask an agent to do with a Postgres database are things you would never let it do to the live one — try the migration, rewrite the query, see what the schema change breaks. Neon makes that safe in a way a plain connection cannot: a branch is a full copy of the data that costs almost nothing and can be thrown away. The agent gets somewhere real to work, and production is not it.

In the connector catalogue: Manage Postgres projects, create branches, run SQL.

Things you could ask for

Written the way you would actually say them. An agent plans the steps itself.

“Branch production, run this migration against the branch, and tell me exactly what it would change before I go near main.”
“Spin up a branch from production so I can reproduce the bug in this ticket against real data.”
“This query got slow. Read the plan, say why, and suggest the index — then show me the difference on a branch.”
“Which tables have grown fastest this month, and which of them are filtered on a column with no index?”
“Draft the SQL for this schema change and check it against the current schema for anything it would break.”

This connector can run SQL, and “run SQL” includes the statements you would not want run twice. Branching is the reason connecting a database to an agent is a reasonable thing to do at all: ask for the work to happen on a branch, read what it did, and apply it to main yourself.

Connecting it

1Create a Burrak account — the free plan is enough to try this.
2Open Connectors and choose Neon.
3Authorise Burrak in Neon's own window. Your password never reaches us; we receive a token you can revoke whenever you like.
4Give an agent a task. It will use the connector when the work calls for it.

Start free How connectors work

Neon and Burrak, in practice

Can it run SQL against my production database?: Yes — the connector reaches whatever your Neon account reaches, and that includes main. We would not tell you to rely on politely-worded instructions to prevent it. Say “on a branch” in the brief, and treat applying anything to main as a step you take, not one you delegate.
What does branching actually buy me here?: A branch is a copy-on-write copy of your data, so it comes up in seconds and holds the real rows rather than a thin fixture. That matters for the jobs worth handing over: a migration that passes against an empty schema tells you nothing, and a query plan is only honest against realistic data. When the agent is done you delete the branch and nothing it did survives.
Does it see my data, or only the schema?: It sees whatever its queries return, so on a database holding customer records a broad SELECT puts those records in the conversation. If that is your situation, the same branching answer applies for a different reason: work on a branch you have anonymised, or keep the agent to schema and plan questions where it never needs to read a row.