How to connect Claude or ChatGPT to your company data (without regretting it)

Your team already uses Claude or ChatGPT every day. Your company data sits in Postgres, Snowflake, or BigQuery. Connecting the two seems like it should be simple, and for one person, it is.

The hard part is doing it for a team without creating problems you'll spend the next quarter cleaning up.

I've set this up for marketplaces, e-commerce ops teams, and expedition companies, from 2-person startups to 100-person teams. This page covers the whole picture: what your options are, where each one works, where each one breaks, and what “safe” actually means when an AI can query your production data.

What are your options for connecting AI to company data?

Every setup falls into one of two patterns.

Pattern 1: Direct connection. You run an MCP connector (or use a built-in integration) that gives the AI direct access to your database. Fast to set up, works well for one technical person.

Pattern 2: Governed access layer. In plain words: a layer that manages access. The AI talks to it instead of talking to your database, and it handles who can see what, what the tables mean, what queries ran, and what the answers were based on.

Most teams start with Pattern 1 and hit its limits within weeks. Understanding those limits upfront saves you the false start.

How does a direct MCP connection work?

A direct MCP connection takes about ten minutes:

1. Create a read-only database user
2. Install an MCP server (there are open-source ones for every major database)
3. Point your AI tool at it

Now Claude can list your tables, inspect your schema, and run SQL. Ask “how many signups last week?” and it writes the query, runs it, and gives you the answer.

For a solo technical founder exploring their own database, this is genuinely great. You know your schema, you can read the SQL it generates, and you notice when something looks wrong.

Why does the direct connection break for teams?

The direct connection has five problems that only show up when the second, third, and tenth person start using it. And they show up fast, because team usage is not a trickle: when Tilt, a live-auction marketplace, rolled out AI access to their team, they ran 4,000+ queries in the first month. That's the volume your setup is handling on day 30.

Everyone sees everything. One connection string means one level of access. Your marketing lead can query payroll. Your contractor can query customer PII. Postgres roles can scope this, but now you're managing database users for every person and every AI tool.

Answers are inconsistent. The AI guesses what “revenue” means from your column names, and each conversation guesses fresh. In our own query logs, we watched a user ask a plain question, “what's our average order value?”, and Claude work through six wrong column guesses before landing on the right one:

SELECT AVG(ORDER_TOTAL) FROM orders;   -- invalid identifier
SELECT AVG(AMOUNT) FROM orders;        -- invalid identifier
SELECT AVG(TOTAL_AMOUNT) FROM orders;  -- invalid identifier
SELECT AVG(VALUE) FROM orders;         -- invalid identifier

The connection worked perfectly the whole time. But two people asking the same thing will not reliably get the same number, and neither will the same person on different days. This is the problem golden queries exist to solve: canonical, vetted SQL for the questions your team asks repeatedly, stored where the AI can reuse them instead of re-deriving the metric every session. It's also how real rollouts work: Quark Expeditions curated the common questions their marketing and ops teams ask before opening up access, so those answers come from vetted queries, not fresh guesses.

Credentials sprawl. Each person configures their own connector with the database password in a local config file. Someone leaves the company, and you're rotating credentials for everyone.

No visibility. Nobody knows what questions are being asked, what SQL ran, or whether the answers were right. When a wrong number surfaces in a decision, there's no trail to trace.

Context doesn't persist. You correct the AI's misunderstanding of your schema today. Tomorrow, in a new conversation, it makes the same mistake. Your teammate's Claude never learned what yours did.

None of these are AI problems. They're infrastructure problems. The AI is fine; the setup around it is missing.

Is it safe to connect AI to your company database?

When people say they want to connect AI to company data “safely,” they usually mean some combination of these six things:

1. Read-only access to a replica. The AI can never write, and slow queries can't affect production.
2. Scoped table access. Each person or group sees only the tables they should. Sensitive data isn't just protected by hoping nobody asks about it. This is the fix for “everyone sees everything.”
3. Centralized credentials. Database passwords live in one managed place, not on laptops. Offboarding someone means revoking one account, not rotating shared secrets. The fix for credential sprawl.
4. Shared definitions. “Revenue,” “active user,” and “churn” are defined once, by the data team, and every answer uses the same definition. The fix for the ORDER_TOTAL guessing above.
5. Query visibility. A log of who asked what, what SQL ran, and what came back. Not for surveillance, but so wrong answers can be traced and fixed. The fix for having no trail when a wrong number surfaces.
6. Context that stays current. When the schema changes, the AI's understanding updates. Nobody maintains a prompt document by hand. The fix for corrections that evaporate between conversations.

A direct connection gives you #1 if you set it up carefully. The other five are what the governed layer is for.

Direct connection vs governed layer at a glance

For the full build-vs-buy breakdown, including what it costs to close each gap yourself, see DIY MCP server vs Contextflo for teams.

When do you need a governed layer?

Here's how I'd actually decide:

Stay with a direct connection if:

• One technical person is using it
• The database has no sensitive data
• You read every query before trusting the answer
• It's a prototype or exploration, not a workflow

You need a governed layer when:

• More than one person queries the data
• Non-technical people rely on the answers
• The database contains anything sensitive
• Decisions get made from the answers without someone reviewing the SQL
• You'd want to know if an answer was wrong

Claude vs ChatGPT for data analysis: does it matter?

Less than you'd think for the connection itself. Both support MCP connectors, both can run SQL through a governed layer, and both work with every setup described on this page. But there are real differences in how they get connected and how they behave once they are.

Claude treats MCP as a first-class feature: custom connectors are available across paid plans, and adding one is a settings change, not an admin project. In our query logs, Claude is also the more reliable of the two at the multi-step analytical loop: inspect the schema, write a query, hit an error, correct itself, and refine. When it produces charts and dashboards from results, they render in the conversation as artifacts.

ChatGPT gates custom MCP connectors by plan: on Plus and Pro you enable Developer Mode to add one, and on Team and Enterprise a workspace admin has to install the connector before anyone can use it. That admin step matters for rollout planning. Once connected, day-to-day querying is comparable, and if your company already runs on ChatGPT, the rollout friction of staying put is close to zero.

Our recommendation: use whichever tool your team already uses. The worst outcome is forcing people into a new tool; adoption dies there. If you're starting fresh and analytics is the main use case, Claude's MCP maturity gives it the edge today.

Setup guides by database

We've written step-by-step guides for each database, covering both the DIY approach and the governed setup:

• Connect Claude to Postgres
• Connect Claude to Snowflake
• Connect Claude to BigQuery
• Connect Claude to Redshift
• Connect Claude to Databricks
• Connect Claude to ClickHouse

How Contextflo fits

Contextflo is the governed layer. You connect your database once with read-only credentials, then point Contextflo at your context sources: the schema, but also your source code and internal documents, the places where what your data actually means is written down. From those it extracts metadata for every table and column, which the AI agent accesses on demand. Your team connects Claude or ChatGPT to Contextflo, not to the database.

Every person authenticates individually. Access controls scope what each person can query. Every question and every query is logged. Definitions are shared, so everyone gets the same answer to the same question.

This is how Tilt, a live-auction marketplace, runs analytics today: a team of about 60 with one data scientist, where around 80% of the company self-serves through Claude, running 7,000+ queries a month against shared definitions and scoped access. Quark Expeditions followed the same path for their marketing and ops teams: access scoped per team, and the queries each team asks most curated before rollout.

Setup takes about 15 minutes.

Connecting AI to your company data is the easy part. Making it something your whole team can rely on is the actual problem, and it's the one worth solving first.

Frequently asked questions

Contextflo is free for one user and one data source, so you can validate the whole flow before rolling it out.