You don't need a data warehouse for analytics
Most startups run on Postgres + a few SaaS tools. MCP connectors let you query them directly from Claude, no warehouse required.
Most startups start the same way: a Postgres database running the app, Stripe for payments, Amplitude or Mixpanel for product events, HubSpot or Salesforce for CRM. Data lives in 4-5 places. None of them talk to each other.

Until recently, the only way to query across these sources was the “modern data stack”: replicate everything into a warehouse, transform it with dbt, layer a BI tool on top. That's $3,000-10,000/month in tooling and weeks of engineering time before anyone can ask a question.
That's changing. MCP (Model Context Protocol) connectors now exist for most major data sources. You can connect Claude directly to Postgres, Amplitude, Stripe, and others, with no warehouse in between.
Example: Postgres + Amplitude in Claude
Say you're a Series A startup. Your user data and orders live in Postgres. Your product analytics (events, funnels, retention) live in Amplitude. You want to ask questions 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.”
These questions span two systems: user/revenue data in Postgres and behavioral data 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: Amplitude, Stripe, HubSpot, and others. You authenticate via OAuth, and Claude can query their data directly. Ask about retention? It pulls from Amplitude. Ask about revenue? It queries Postgres. Cross-cutting question? It combines both.
No warehouse. No ETL pipeline. No dbt models. Just MCP connectors and a question.
Where this breaks down
This works surprisingly well for a technical founder exploring their own data. But as soon as you try to scale this to a team, the cracks show:
- Everyone manages their own config: Each team member needs to set up their own MCP servers with their own credentials. Your marketing lead isn't editing JSON config files.
- No shared context: Claude sees raw table names like
usr_acct_v2and Amplitude event names likebtn_clk_checkout_v3. Without descriptions, it guesses, and different people get different guesses. - No metric consistency: When your CEO asks “what's our MRR?” and your head of sales asks the same thing, they should get the same number. With raw MCP connectors, Claude generates different SQL each time.
- Credentials everywhere: API keys and database passwords sitting in config files on every laptop. No centralized access control. No way to revoke access when someone leaves.
- No audit trail: You have no visibility into what queries are being run, what answers people are getting, or whether the SQL is even correct.
- Cross-source joins are fragile: Claude can query Postgres and Amplitude separately, but joining results across them requires the LLM to stitch data together in-context. This works for simple cases and breaks for complex ones.
What Contextflo does differently
Contextflo provides managed connectors for all major data sources: Postgres, BigQuery, Snowflake, ClickHouse, Redshift, Databricks, Amplitude, and more. Instead of each person wiring up their own MCP servers, you connect once and your whole team gets access through Claude.
DIY MCP connectors
- Each person configures their own
- Raw schema, no descriptions
- Credentials on every laptop
- No metric definitions
- No query audit
- No access control
Contextflo
- Connect once, everyone gets access
- Auto-generated context for every table
- Centralized credentials, per-user ACL
- Shared metric definitions
- Full query audit log
- Governance out of the box
The connectors are managed. Contextflo handles authentication, schema syncing, and context generation. When your Postgres schema changes or Amplitude adds new events, the context updates automatically.
When you actually need a warehouse
You should invest in a warehouse when:
- You need complex transformations that take minutes to run
- You're joining 10+ data sources with complex relationships
- You need historical snapshots and slowly-changing dimensions
- You have a data team that can maintain the pipeline
For the other 90% of startups querying a Postgres database and a couple of SaaS tools, connecting them directly to Claude with proper context and governance is faster, cheaper, and gets you answers today instead of next quarter.
And when you do eventually add a warehouse, Contextflo works with those too. Same context layer, same Claude experience. Just add the connection.
Get started
Connect your Postgres database and SaaS tools to Contextflo. Setup takes 10 minutes per source. No ETL, no warehouse, no dbt models.
Related reading
- How to use Claude with Postgres: step-by-step setup guide
- How to run analytics without a data team: what Tilt does instead
- What it takes to maintain an agentic analytics stack: the hard parts nobody talks about