I connected Claude — should I point it at production on day one?

Prefer staging or a read replica for the first week. Read-only stops writes; it does not stop reading every email in users. Staging first, table allowlists, then decide if production primary is worth it.

Do I need to know SQL this week?

No. Ask in plain English and optionally ask Claude to show the SQL so you learn your tables. Force describe_table before heavy queries so it doesn't invent column names.

What's the one habit that saves the most pain?

Verify two or three answers you already know (signup count yesterday, a specific customer's plan). If those are wrong, fix connection or definitions before you trust planning numbers.

When should I set up a weekly scheduled report?

After one manual run looks right — usually mid-week. Claude Cowork /schedule on a stable prompt beats automating a wrong definition every Monday.

Is this only for engineers?

No. Founders and ops get the most from week one: fewer Slack-to-eng asks and fewer stale spreadsheet uploads. Engineers still care about staging, allowlists, and Usage logs.

First Week Claude + Database | What to Ask

You pasted the MCP URL into Claude. The connector shows tools. Congrats — and also: the easy part is over.

Week one is where people either build a useful habit or decide “AI on the database” is hype. This is a simple playbook: what to ask each day, what to lock in as rules, and what to postpone.

Not a click-by-click connect guide — assume the endpoint already works. Setup if you still need it: Connect Claude to PostgreSQL (same pattern for other databases). Outcome overview: ask Claude about your database.

Before day one (15 minutes)

Connection is on staging or a replica, not “prod because it’s read-only” (staging first)
Sensitive tables off the allowlist if your gateway supports it (don’t open every table)
You know which Claude surface you’re using (chat vs Cowork)

If half your tables are “missing,” you may be stuck on public only — Postgres schemas beyond public.

Day 1 — Map the territory

Ask:

What tables do I have? Group them by what they seem to be for.
Describe orders (or your core table). What does each column mean in plain English?
What’s the date range of data in that table?

You’re checking that Claude sees the real catalog — not inventing a tutorial schema (why schema hallucination happens).

Day 2 — Known-answer checks

Pick two facts you already know:

Signups yesterday (or last Monday)
One customer’s current plan / status from the admin UI

Ask Claude the same questions. Compare. If it’s wrong, stop and fix definitions or the connection before you plan a launch on AI numbers (verify answers).

Day 3 — Put rules in the project

Paste something like this into Claude project instructions (or your sticky system note):

Database access is read-only via MCP.
Before execute_sql: describe each table you will query.
Never invent columns or status values.
For metrics, state the definition you used.
If unsure, ask — don't guess.
Prefer aggregates over SELECT * dumps.

That one block prevents most column-guessing loops.

Day 4 — One real business question

Something you would have Slack-ed eng or exported for:

Trials that converted in the last 14 days, by plan
Cancellations last week vs the week before
Accounts with no login in 30 days (only if those events exist in this DB)

Ask for the SQL. Skim it. If “active users” looks fuzzy, read metric traps before you trust the label.

Day 5 — Excel as output, not input

Need a sheet for a meeting? Ask for a CSV-ready table (capped rows), download/copy into Sheets. Don’t re-upload last week’s export as the source of truth — stop uploading Excel to Claude for company KPIs that live in the DB.

Day 6 — Manual “weekly” report once

Run the Monday-style prompt by hand (signups, conversions, cancellations, short summary). Fix table names. Save the prompt. Don’t schedule yet.

Full prompts: Cowork weekly reports or Claude Code weekly reports.

Day 7 — Schedule or stop

If day 6 looked right: /schedule weekly in Cowork (or your Code scheduler).
If it still feels shaky: keep asking ad-hoc another week. Automating confusion is worse than no automation.

Glance at Usage / audit logs after the first scheduled run.

What not to do in week one

Point at production primary “just to see”
Ask for LTV / cohorts with no definition in the schema
Dump the entire users table into chat
Schedule a report you haven’t verified once
Treat Claude as a write-back cleaner (gateway read-only is a feature)

End of week checklist

[ ] Claude lists the tables you care about
[ ] Two known answers match
[ ] Project rules say describe-before-SQL
[ ] One real ops/founder question answered with SQL shown
[ ] Optional: one weekly prompt saved; schedule only if verified

Week one isn’t about clever prompts. It’s about trust: right environment, right tables, right definitions, then cadence. After that, Claude on your database stops being a demo and starts replacing the export ritual.

Read-only MCP gateway: mcpserver.design.

Related reading: