Back to Blog

How to Explore an Unfamiliar Database With AI

Inherited a Postgres schema with no docs? Use Claude or Cursor on a staging connection to map tables, relationships, and gotchas — without guessing column names or dumping production PII.

You join a team (or inherit a side project). Docs are a stale Notion page and twelve migrations named fix_users_again.

You don’t need the whole schema on day one. You need: what’s here, how it connects, where the footguns are.

Claude or Cursor on staging can do that — not production, not guessing in an empty chat.

Setup: Connect Claude to PostgreSQL / Cursor. Also: staging first, table allowlists, where results go.

Before you ask anything

  1. Staging (or sanitized) connection only
  2. SELECT-only user if you can
  3. Allowlist: skip tables that are clearly secrets/tokens if you’re just mapping the product
  4. Confirm tools work: “List the tables.” — if it invents names, the connector isn’t live (troubleshooting)

Prompt pack: first hour

Tour

Read-only access. Inspect the real schema.
Give me a one-page tour:
- core entity tables (users/accounts, workspaces/orgs, main product objects)
- how they relate (FKs or obvious id columns)
- timestamp and status columns that look important
- anything that looks like soft delete or PII-heavy
Don't invent tables. Cite names you actually saw.

Relationships

For the main "user/account" table and the main "order/subscription/project"
table (pick based on what exists), explain how they join.
Show example SQL for: accounts created in the last 7 days with no
related product object yet.

Footguns

Look for soft-delete columns, status enums, and renamed legacy tables.
List DISTINCT status values on the 2–3 most important tables.
Flag columns that look deprecated (null rate high, names like old_*).

Draft glossary

Draft a short data dictionary for the 10 most important tables:
name, purpose in one sentence, key columns, how you'd count "active" rows.
Mark anything you're unsure about with UNCERTAIN.

Save the glossary in the repo. Next hire starts warmer.

What to verify with a human

AI is fast at listing columns. It’s weak at tribal knowledge:

  • Which status means “money in the bank”?
  • Is users or profiles the one support means?
  • Is staging’s data recent enough to trust counts?

Spend fifteen minutes with someone who’s been there. Bring the draft glossary. Fix the UNCERTAIN lines.

Also run known-answer checks on one count you can confirm in the admin UI — catches wrong connection early.

Day-two prompts (still on staging)

  • “Where would I look to see if a customer hit an activation event?”
  • “Which tables would a weekly signup report need?” — then steal ideas from weekly reports
  • “Any orphan child rows for order_items → orders?”

When definitions get slippery, read metric traps.

Don’t do this while onboarding

  • Point the explorer session at production “just to see real volumes”
  • Dump SELECT * FROM users LIMIT 1000 into chat
  • Ask for “our LTV” before you know if charges exist in this DB
  • Trust a beautiful ERD the model drew without opening list_tables

After the map exists

  • Keep the staging endpoint for exploration
  • Add a replica later if you need current prod-shaped numbers
  • Share staging with teammates carefully (team sharing)
  • Use migration checks before you ship schema changes against what you just learned

Walk the live catalog once on staging. AI shortens the walk; staging keeps it safe.

mcpserver.design (7-day Solo trial) — tour prompt first.

Related reading:

← Back to Blog