How to chat with your Postgres database in 5 minutes

If you’ve ever stared at a Postgres database and wished you could just ask it questions, this post is for you. We’re going to connect a Postgres instance to Tablize, ask a question in plain English, and save the answer so it keeps running.

Total time: about 5 minutes. You’ll need a Postgres connection string (anything from a Supabase project to a self-hosted RDS instance) and a free Tablize workspace.

Step 1: Create a read-only role in Postgres (90 seconds)

This is the only part that touches your database directly. We’re creating a Postgres role with read-only access to the schemas you want Tablize to query, and nothing else. Even if you trust Tablize completely, read-only is the right default — agents make mistakes, and a DROP TABLE is harder to recover from than a “permission denied.”

Run this in psql or your favorite SQL client:

-- Create a role just for Tablize
CREATE ROLE tablize_ro LOGIN PASSWORD 'use-a-long-random-password';

-- Grant connect on the database
GRANT CONNECT ON DATABASE your_db TO tablize_ro;

-- Grant usage on the schema(s) you want Tablize to see
GRANT USAGE ON SCHEMA public TO tablize_ro;

-- Grant SELECT on all existing tables
GRANT SELECT ON ALL TABLES IN SCHEMA public TO tablize_ro;

-- And on future tables created in this schema
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO tablize_ro;

If you have multiple schemas you want exposed, repeat the USAGE/SELECT/ALTER DEFAULT PRIVILEGES block for each. If you have schemas you want hidden (like internal or migrations), simply don’t grant USAGE on them.

The connection string for Tablize will look like:

postgresql://tablize_ro:use-a-long-random-password@your-host:5432/your_db

Step 2: Connect in Tablize (60 seconds)

Open your Tablize workspace, go to Integrations in the sidebar, and click Postgres. Paste the connection string. Hit “Test connection.” If Postgres can be reached and the credentials work, you’ll see a green check.

Tablize will then run an automatic schema introspection — it walks every table, reads the column names and types, and stores a lightweight representation. This is what lets the agent answer questions without you describing the schema first. The introspection is read-only and happens once on connect, then incrementally when tables change.

For a database with a few dozen tables, this takes about 10 seconds. For one with thousands of tables, more like a minute. Either way, you don’t need to wait — you can open a chat tab and start typing while the agent indexes in the background.

Step 3: Ask your first question (30 seconds)

Open a new chat. Type something specific. Don’t say “show me my data” — that’s too vague. Try something a junior analyst would understand immediately:

"Show me the top 10 customers by total order value in the last 90 days,
 with their order count and their average order value."

The agent will:

1. Look at your schema and identify the customer and order tables (it makes a guess if the naming is ambiguous and tells you).
2. Write the SQL — typically a JOIN with a GROUP BY and an ORDER BY ... LIMIT 10.
3. Show you the SQL before running it. You can edit it if the join key is wrong, or just hit run.
4. Run the query against your read-only role.
5. Show you the result table, and write a 1-2 sentence summary of what’s interesting.

The whole thing usually takes 5-15 seconds. The first time the agent works with a new table, it’s slower as it builds intuition. By the third question, it’s fast.

Step 4: See and edit the generated SQL

This is the bit that matters for trust. Tablize doesn’t hide the SQL from you. Every query is shown in full, syntax-highlighted, and editable. If you know SQL, you can read what the agent wrote and decide whether you trust it. If you don’t know SQL, you can still ask follow-up questions to interrogate the logic — “why did you use a LEFT JOIN here?” — and get a plain-English answer.

A common pattern: the agent writes a query that’s almost what you want, but the cutoff date is wrong, or it’s grouping by the wrong dimension. Instead of re-prompting, you can edit the SQL directly and re-run. The agent treats your edit as the new source of truth and remembers it for the next related question.

If the SQL is doing something genuinely strange — say, a window function you don’t recognize — ask the agent to explain it. It will. Plain-English explanations of generated SQL are one of the underrated wins of this whole category.

Step 5: Save the answer so it keeps running

This is the step that distinguishes the Data Agent shape from “ChatGPT with a database tool.” At the bottom of any agent response, you’ll see a Keep bar with options:

• 📝 Save as Report — turn this analysis into a markdown report that re-runs on demand.
• 💾 Save as Script — save the SQL or Python as a reusable script you can run on different parameters.
• 🔍 Watch this — set up a condition and get pinged when it triggers.
• 📱 Build a dashboard — generate a small dashboard around this analysis.

For our top-10-customers example, Save as Report with a weekly schedule is the natural move. The report shows up in your Sidebar under Reports, and Monday at 9 AM (or whatever time you pick) it re-runs against fresh data and lands in your inbox.

You’ve now turned a one-off question into a recurring brief, without writing any code or building anything.

What to ask next

If your first question worked, here are five second questions that will exercise different muscles:

• A funnel: “Walk me through my user signup funnel from landing page to first action, week-over-week for the last 8 weeks.”
• A cohort: “Show me 12-month retention by signup cohort for the last 12 months.”
• An anomaly: “Are there any tables where row count grew more than 50% in the last 30 days?”
• A build: “Build me a CRUD admin for the users table with search and a role filter.”
• A watch: “Alert me if the count of failed login attempts in the last hour exceeds 100.”

Each of these exercises a different part of the agent. The cohort tests its SQL chops on a real analytical pattern. The anomaly tests its ability to introspect schema metadata. The build tests its code generation. The watch tests its scheduling and notification plumbing.

Common gotchas

A few things that catch new users out:

The schema isn’t what you think it is. Sometimes a column called created is actually a status field, and a column called created_at is the timestamp. The agent guesses based on naming, and sometimes guesses wrong. If a query result looks weird, check the SQL first — the join key or filter column might be off.

Read-only doesn’t mean fast. If you have a 100M-row events table without proper indexes, a join against it will be slow. Tablize will time out long-running queries to protect your database — if you hit this, the fix is usually to add an index, not to change anything in Tablize.

The agent will ask before doing anything destructive. It can’t DROP TABLE from a read-only role anyway, but even with write access it goes through the Confirmation Center before mutations. There’s no situation where a wrong question causes a wrong action.

What’s next

Once you have one analysis saved, the natural next step is to chain it — build a Watch on top of the Report, or generate a Dashboard from the saved Script. The Keep loop is the differentiator, and once you’ve done it once, you understand the shape.

Try Tablize free on your own Postgres →

---

Related reading:

• What is a Data Agent?
• Build a Shopify revenue dashboard from one sentence
• The Postgres integration page