How to Set Up a Postgres MCP Server With Gemini CLI
I inherited a Postgres schema with 94 tables last year. No ERD, minimal comments, just 94 tables and a pile of legacy migrations. I needed to understand it fast. I tried a few AI tools, and most of them would hallucinate column names or confidently join on columns that didn't exist by the time I got to table 30. Gemini CLI was different because of one thing: the context window is enormous. I could dump the entire schema and it still had room to reason about relationships. That's what made it click for this kind of work.
This post walks through connecting that schema (or yours) to Gemini CLI via QueryBear's MCP server so you can ask questions in plain English and get real answers.
Part of the Postgres MCP Server guide.
What you'll need
- A Postgres database (read replica recommended, but any Postgres URL works)
- A QueryBear account
- Gemini CLI installed (
npm i -g @google/gemini-clior via Homebrew)
Why route through a gateway
Handing Gemini CLI a raw postgres:// URL means the agent has write access unless you've locked the role down perfectly. A gateway like QueryBear sits in front: it rejects DML and DDL at the parser level, enforces a table allowlist, masks sensitive columns, and logs every query. The full breakdown is in the Postgres MCP Server guide.
Connect QueryBear to your Postgres
- Open the QueryBear dashboard and click "New connection."
- Pick "Postgres" and paste your connection URL. A read replica with a
SELECT-only role is the right default. - Under "Allowed tables," pick which tables Gemini should be able to see. Leave off anything with secrets or PII you haven't thought through.
- Under "Blocked columns," add anything you don't want in the agent's context window:
password_hash,totp_secret,ssn_last_4. Save.
That's it. QueryBear is now standing between Gemini and your database.
Install the QueryBear MCP server in Gemini CLI
Open (or create) ~/.gemini/settings.json and add the mcpServers block:
{
"mcpServers": {
"querybear": {
"httpUrl": "https://mcp.querybear.com/mcp"
}
}
}Gemini CLI reads this file on every invocation, so no restart is needed. Save the file and the next Gemini session picks it up automatically.
Ask your first question
I asked Gemini: "Which products have the highest return rate this quarter?"
Gemini called get_schema first, pulled the allowlisted tables, then generated this:
WITH q AS (
SELECT date_trunc('quarter', now()) AS start
)
SELECT
oi.product_id,
COUNT(r.id)::float / NULLIF(COUNT(oi.id), 0) AS return_rate
FROM order_items oi
LEFT JOIN returns r ON r.order_item_id = oi.id
JOIN orders o ON o.id = oi.order_id
CROSS JOIN q
WHERE o.created_at >= q.start
GROUP BY oi.product_id
ORDER BY return_rate DESC
LIMIT 20;QueryBear ran it through the parser (no DML, all tables on the allowlist), executed against the replica, and returned 20 rows. Gemini formatted them as a markdown table in the terminal. Total round trip was under two seconds.
The NULLIF(COUNT(oi.id), 0) is good defensive SQL. Gemini generated that on its own because it saw from the schema that orders can have zero items after cancellations.
A Gemini-specific tip
Settings.json hot-reloads. If you add a new MCP server mid-session or change the httpUrl, you don't have to quit and reopen Gemini CLI. The next query you run will use the updated config. This is useful when you're toggling between a staging and production QueryBear connection during a debugging session: edit the file, keep going.