StarterPG

starterpg gives you a real Postgres database without running one. This listing puts it in your agent.

The gap it closes is small and constant. You are writing code against a database and you need to know what is actually in it - the column names, whether that table has any rows, how many signups came in yesterday. Today that means leaving the editor, opening a dashboard, finding the project, running a query, coming back. Every time.

So the tools cover that loop and nothing else. list_projects says what exists and whether it is usable. get_schema returns the tables and columns, which is the call an agent should make before writing any SQL - without it, it guesses column names from the question it was asked, and a guess that happens to match a different column is worse than one that fails. run_sql runs the statement as your own database role and returns the rows, or the real Postgres error with its hint and position.

run_sql is read-only unless you say otherwise. That is not a security boundary and is not sold as one - the agent holds your role's grants and Postgres decides what it can do, exactly as the SQL editor does. It is a guard against a different failure: a human typing DROP TABLE has decided to, while an agent can be talked into one by a badly-worded request or a hostile string in data it just read. Writes need allow_write on that call.

What the tools deliberately cannot do is as considered as what they can. No creating or deleting projects, no key rotation, no restores, no billing, no RLS policy edits. Each of those either spends money the moment it is called or changes who can read your data, and neither is a decision to arrive at conversationally.

Full product at starterpg.com.