Ask anything of a full copy of your real data

Why point the connection at a branch?

Because a branch is a real database with your real data in it, and nothing an agent does inside one reaches the primary. Schema questions, row counts, a query that turns out to lock something, an UPDATE with a filter wider than intended. All of it happens in a copy you delete afterwards.

That flips the setup work. Instead of an hour designing a role that can read exactly eleven tables, you spend two minutes creating a branch and a role on it that can do whatever it likes. If the answer looks right, re-run the safe version against the primary yourself.

What can a companion do once Neon is connected?

The actions Neon Postgres’ API exposes.

The list is in the Available tools section of the Neon entry under `strawberry://settings/integrations`, with the read-only ones marked. Read it before you plan a workflow.

Alongside it, the Permissions block sets each action to Ask every time, Always allow, or off, and consequential steps stop at an approval card anyway. On a throwaway branch, Always allow on reads is a defensible setting. On the production branch it is not, and that difference is the whole point of the branch.

Expect a cold start, then delete the branch

Compute autosuspends when idle, so the first query after a quiet period pays a cold start.

An agent that opens a connection, thinks, and queries again a minute later hits that more often than you would expect, and it looks like slowness rather than a setting. The pooled connection endpoint suits this short, bursty access.

Branches hold storage and accumulate if nobody deletes them. Delete the branch when the question is answered. It costs one call and saves the "which of these fourteen is real" conversation.

• Create a branch for the connection; keep the primary out of the credential entirely.
• Use the pooled connection endpoint for bursty access.
• Expect a cold start after idle time, and do not read it as a broken connection.
• Delete branches when done, or they pile up and cost storage.

Trace a bad row back to the deploy that made it

A Neon-backed app lives next to a deployment platform, an error tracker and a repository, and the interesting questions cross all four. A row that looks wrong, the deploy that introduced it, the exception that fired eleven minutes later, the issue nobody filed.

A companion holding the Neon connection plus your signed-in Vercel, Sentry and GitHub accounts assembles that trail in one pass, in the time the first tab used to take. If the output is a postmortem, automating incident postmortems is the neighbouring page.

Frequently asked questions