Cross-Source Analysis
Correlate data across databases, warehouses, CRMs, and storage in one conversation.
Your revenue data is in Snowflake. Customer details are in Salesforce. Support tickets are in Jira. Getting a complete picture usually means exporting from each system and pasting into a spreadsheet, or filing a ticket with the data team and waiting.
You can do this in a single conversation instead.
How it works
Each query's results are cached in DuckDB in your workspace. Once you have data from multiple sources, your AI joins them locally. No data leaves your workspace. No expensive warehouse cross-join. No CSV exports.
Example: Snowflake + Salesforce in the demo workspace
The demo workspace has both a Snowflake warehouse and a Salesforce org. Here's what a cross-source session looks like in Claude Code:
Pull all customers from Snowflake and all accounts from Salesforce.
AI calls query("snowflake-demo-datasource", "queries/snowflake-demo-datasource/all_customers.sql")
-> 10 customers -> cached in DuckDB table: all_customers
AI calls query("salesforce-demo-datasource", "queries/salesforce-demo-datasource/accounts.sql")
-> 20 accounts -> cached in DuckDB table: accountsJoin them in DuckDB. Do any customers appear in both systems?
AI writes queries/DUCKDB/cross_source_join.sql
AI calls query("DUCKDB", "queries/DUCKDB/cross_source_join.sql")
AI: No matches by name. The Snowflake CUSTOMERS table uses individual
names (Alice Johnson, Charlie Brown) while Salesforce Account uses
company names (The Virtual Viper, Crystal Fortress).
These datasets don't share a direct join key. To link them, you'd
need a mapping table or a shared identifier like email or account ID.
I'd recommend documenting this in RULES.md so future queries don't
attempt this join.This is a realistic outcome. Cross-source joins depend on knowing which fields match between systems - and sometimes they don't. Discovering that early saves time.
How real teams use this
RevOps across Salesforce + Athena + ClickUp. A RevOps team combines account ARR and opportunity data from Salesforce, usage metrics from Athena, and project tasks from ClickUp. One conversation gives them a view that would otherwise require three dashboards and a spreadsheet. Their power user ran 3,286 commands across 21 active days, primarily doing account-level analysis joining CRM and warehouse data.
Restaurant analytics across ClickHouse + Athena + HubSpot. An operations team queries kitchen scores and order flow from ClickHouse, event data from Athena, and deal pipeline from HubSpot. They use DuckDB to join location-level performance with deal stages to understand which restaurant locations drive the most revenue.
Spend management on Snowflake. A finance team queries invoices and orders from Snowflake, then reconciles against procurement data. The DuckDB cache lets them iterate on the reconciliation without re-querying the warehouse.
Best practices
Document join keys in RULES.md. Cross-source joins depend on knowing which fields match between systems. Write them down: salesforce.accounts.external_id = postgres.companies.crm_id. See Context (RULES.md).
Cache reference data early. If you'll join against a customer list or product catalog repeatedly, ask your AI to load it into DuckDB at the start of the session.
Build incrementally. Start with two sources, get the join working, then add a third. Debugging a three-way join is harder than building up step by step.