You don't need a data warehouse for analytics

Most teams' data lives in four or five places at once: a Postgres database running the app, Stripe for payments, Amplitude or Mixpanel for product events, HubSpot or Salesforce for CRM. None of them talk to each other, and the usual advice is to copy all of it into a warehouse before you can ask a single question across them. You can query them where they already live instead.

Until recently the only way to query across those sources was the modern data stack: replicate everything into a warehouse, transform it with dbt, layer a BI tool on top. That is $3,000–10,000 a month in tooling and weeks of engineering before anyone can ask a question.

That is changing. MCP connectors now exist for most major data sources, so Claude can talk to Postgres, Amplitude, Stripe and others with no warehouse in between.

Example: Postgres and Amplitude in Claude

Say your user data and orders live in Postgres, and product analytics live in Amplitude. You want to ask things like:

What's the 30-day retention for users who came from the Google Ads campaign vs organic?

Show me revenue per user segment, broken down by their most-used feature.

Both span two systems: revenue in Postgres, behaviour in Amplitude. With MCP connectors you can wire both into Claude:

// claude_desktop_config.json
{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://read_user:pass@host:5432/mydb"
      ]
    },
    "amplitude": {
      "url": "https://mcp.amplitude.com/mcp"
    }
  }
}

Most major SaaS tools now offer remote MCP servers. You authenticate over OAuth and Claude queries their data directly. Ask about retention, it pulls from Amplitude. Ask about revenue, it queries Postgres. Ask something crossing both and it combines them.

No warehouse, no ETL pipeline, no dbt models.

Where this breaks down

This works well for a technical founder exploring their own data. Scale it to a team and the cracks show:

• Everyone manages their own config. Each person sets up their own MCP servers with their own credentials. Your marketing lead is not editing JSON config files.
• No shared context. Claude sees usr_acct_v2 and btn_clk_checkout_v3. Without descriptions it guesses, and different people get different guesses.
• No metric consistency. When the CEO asks for MRR and the head of sales asks the same thing, they should get the same number. With raw connectors, Claude writes different SQL each time.
• Credentials everywhere. API keys and database passwords in config files on every laptop. No central access control, no way to revoke when someone leaves.
• No audit trail. No visibility into what is being asked, what answers came back, or whether the SQL was right.
• Cross-source joins are fragile. Claude can query Postgres and Amplitude separately, but stitching results together in context works for simple cases and breaks on complex ones.

The second and third points are the ones that bite quietly. A broken config announces itself. Two people getting different MRR does not, until it surfaces in a meeting.

What Contextflo does differently

Contextflo provides managed connectors for the major sources: Postgres, BigQuery, Snowflake, ClickHouse, Redshift, Databricks, Amplitude and more. That list mixes production databases and warehouses on purpose. It works whether or not you run a warehouse, so you can start on the Postgres you already have and get governed answers without a migration first. Instead of each person wiring up their own servers, you connect once and the whole team gets access through Claude.

DIY MCP connectors	Contextflo
Each person configures their own	Connect once, everyone gets access
Raw schema, no descriptions	Generated context for every table
Credentials on every laptop	Centralised credentials, per-user ACL
No metric definitions	Shared metric definitions
No query audit	Full query audit log
No access control	Governance out of the box

The connectors are managed, so authentication, schema syncing and context generation are handled. When your Postgres schema changes or Amplitude adds events, the context updates.

When you actually need a warehouse

Invest in one when:

• You need complex transformations that take minutes to run
• You are joining ten or more sources with complex relationships
• You need historical snapshots and slowly-changing dimensions
• You have a data team who can maintain the pipeline

That third one is the one people skip and later regret. Querying live sources always shows you the present. If you need to know what a customer's plan was in March, and the source row has since been overwritten, no amount of connecting will recover it. A warehouse is partly a query engine and partly a memory, and only the query half is easy to replace.

If your data lives in a Postgres database and a handful of SaaS tools, connecting them directly with proper context and governance gets you governed answers this week instead of after a warehouse migration.

And when you do add a warehouse, the same context layer works. Just add the connection.