Do these prompts work without a live database connection?

Not well. Without MCP or similar, the model invents tables or needs a pasted CSV. Connect first — then these prompts pay off.

Which client should I paste them into?

Claude, Cursor, or ChatGPT — whichever has your database connector enabled. For recurring Monday jobs, see the Claude Code weekly reports post.

Why do the prompts say 'inspect the schema first'?

So the model lists real tables and columns before writing SQL. That cuts down invented names. You should still verify important numbers with known-answer checks.

Can I ask for LTV in one prompt?

Only if your tables support a definition you accept. The LTV prompt below forces the model to show its formula or refuse. Vague 'what's our LTV?' without columns produces confident nonsense.

Are these safe on production?

Prefer staging, SELECT-only, and table allowlists. Prompts that touch customers should avoid dumping emails into the chat.

AI Database Prompts | Claude Cursor ChatGPT

Database connected, empty chat open — now what? That’s the blocker for a lot of people who don’t write SQL every day.

These prompts assume a live, read-only connection (Claude, Cursor, or ChatGPT via MCP). Each one tells the model to inspect your schema and show its SQL.

Not connected yet? Can AI see my data? then Connect Claude to PostgreSQL (same idea for Cursor / ChatGPT).

Recurring Monday jobs: weekly reports with Claude Code. Cancel deep-dives: why customers cancelled.

Rules to put above any prompt

Paste this once at the start of a thread (or save it as a snippet):

You have read-only access to my database via MCP.
Before any business question:
1. List relevant tables/columns (inspect — don't assume names)
2. Prefer SELECT aggregates over dumping raw PII
3. Show the SQL you ran
4. If a metric can't be computed from this schema, say what's missing
Never invent tables, columns, or status values.

1. Schema tour (first session)

Give me a short tour of this database:
- main tables and what they seem to be for
- how users/accounts relate to orders or subscriptions if those exist
- columns that look like timestamps, status, or money
Keep it under one page. Flag anything that looks like secrets or raw tokens
(I may remove those from the allowlist).

2. Signups this week vs last week

Define "signup" from the actual schema (don't guess).
Then report:
- signups this calendar week vs last calendar week
- absolute and percent change
Show SQL. If timezone is ambiguous, state which TZ you used.

3. New vs returning

Using only tables we have, can we tell new signups apart from returning users
or repeat purchasers? If yes, compare this week vs last week.
If the data model can't support "returning," say so clearly and stop.

4. Activation (did they do the important thing?)

Propose an activation definition from events or tables we actually store
(e.g. created a project, first API call, connected a database).
Then: of users who signed up in the last 14 days, what share activated within 7 days?
If we don't log activation, say what's missing.

5. Simple revenue-ish check

If we store payments, invoices, or subscription amounts in this DB,
summarize recognized or charged amount for the last 30 days vs the prior 30.
State the exact columns and any currency assumptions.
If revenue lives only in Stripe and isn't synced here, say that — don't invent MRR.

6. Cautious “LTV” (or refuse)

I want a rough customer LTV from this database.
First tell me whether we have enough (charges, account age, churn dates).
If yes, show a simple formula in SQL and the result for the last 90 days of new customers.
If no, list the missing pieces. Do not output a fake LTV number.

7. Cancellations snapshot

Count cancellations or unsubscribes this week vs last week.
Use real status/date columns. Show SQL.
Do not explain "why" unless a reason field exists — counts only.

(For the “why” follow-up, use the longer prompts in ask AI why customers cancelled.)

8. Data quality smell test

Find obvious data quality issues in the core tables I care about
(orders, subscriptions, or users — whichever we allow):
null-heavy required fields, duplicate emails if present,
orphan child rows, future timestamps.
Limit to a handful of findings with counts. SELECT only.

9. “Explain this number” (after a dashboard disagreement)

Finance says metric X is N. Using this database, try to reproduce N.
Show the SQL. If you get a different number, list the likely definition gaps
(status filters, timezone, deleted rows). Don't declare a winner — show the work.

Then verify against a query you trust.

Habits that keep prompts honest

Staging first for exploration; production only when you need current truth
Allowlist analytics tables; leave full identity dumps off
Ask for SQL every time until you trust the thread
Refuse LTV/churn-why when columns aren’t there — a good refusal is a feature
Schedule only after a manual run looks right (Claude Code weekly reports)

Keep the rules block and two or three prompts you’ll actually reuse. The connection does live reads; the prompt keeps the model from inventing your schema.

Staging connection: mcpserver.design (7-day Solo trial) — schema tour, then signup comparison.

Related reading:

Weekly Database Reports with Claude Code — put prompt #2 on a Monday schedule
Ask AI Why Customers Cancelled — when counts need a deeper look
How to Verify AI Answers About Your Database — known-answer checks
Ask Claude About Your Database — plain-English workflow
Talk to Your Database Without an Analyst — why ad-hoc access matters
When Not to Connect AI to Your Database — when BI or paste is enough