How to Set Up a Postgres MCP Server With Cursor
I was three hours into a payment refactor when I realized I had no idea how many orders were actually failing. The code was in front of me. The database was... somewhere else. I had a terminal open, a psql session I'd closed an hour ago, and a growing suspicion that the answer I needed was one query away. That context switch to open TablePlus, reconnect, remember the right table name, and type the SQL felt like it cost me fifteen minutes I didn't have.
That's the problem this setup solves. You're already in Cursor. You should be able to ask your database a question from there.
Part of the Postgres MCP Server guide.
What you'll need
- A Postgres database (read replica strongly recommended)
- A QueryBear account
- Cursor installed
Why route through a gateway
Pasting your DATABASE_URL directly into an agent's environment gives it the same blast radius as your database user. A gateway like QueryBear sits in between: its SQL parser rejects anything that isn't a SELECT, an allowlist controls which tables are visible, and every query goes into an audit log. The Postgres MCP Server guide covers the full security model if you want the details.
Connect QueryBear to your Postgres
- Open the QueryBear dashboard and click "New connection."
- Choose Postgres, then paste your connection URL. Use a read replica if you have one, and a role with
SELECTonly. - Under "Allowed tables," pick the tables you want the agent to see. Leave sensitive tables off the list.
- Under "Blocked columns," add anything that shouldn't appear in context:
password_hash,totp_secret, anything PII-adjacent. Save.
Install the QueryBear MCP server in Cursor
Cursor reads MCP config from ~/.cursor/mcp.json for global setup, or .cursor/mcp.json at your project root if you want to share it with your team via git.
Edit whichever file makes sense and add:
{
"mcpServers": {
"querybear": {
"url": "https://mcp.querybear.com/mcp"
}
}
}Restart Cursor, then open a chat window. You should see QueryBear available as a connected tool. If you want to verify, open the command palette with cmd-shift-P and search for "MCP" to see the active server list.
Ask your first question
Back to that payment refactor. I asked Cursor:
"Show me the orders that failed payment in the last 24 hours."
Cursor called get_schema through QueryBear to figure out the table structure, then generated this query:
SELECT id, user_id, amount, failure_reason, created_at
FROM orders
WHERE status = 'failed'
AND created_at >= now() - interval '24 hours'
ORDER BY created_at DESC;QueryBear ran it against the replica, checked it against the allowlist, and handed back the results. Cursor showed me 47 rows. I could see the failure_reason breakdown without leaving the file I was editing.
The whole thing took about four seconds. The psql approach would have taken me out of flow completely.
Worth mentioning: Postgres's interval syntax is one of those things that trips up agents sometimes. If you ask about a specific time window and the results look off, check that the generated SQL is using interval '24 hours' and not a hardcoded timestamp. The agent usually gets it right, but it's worth a glance at the generated query the first couple of times.
A Cursor-specific tip
If you're working on a shared codebase, commit .cursor/mcp.json to the project root. Anyone who clones the repo and opens Cursor gets QueryBear connected automatically, no setup required. Just make sure everyone has a QueryBear account and is authenticated.
This is the move for teams. One PR adds it. Everyone benefits. No one has to remember to set it up.