Two camps have formed in the RevOps community, and both are partially right. Camp one says centralize everything in a data warehouse. Snowflake, BigQuery, or Databricks becomes your single source of truth. All revenue data flows in, gets modeled, and gets queried from one place. Camp two says warehouses are too slow for revenue operations. They want connected data models with shared identifiers and event streams that preserve real-time signals across tools.
The warehouse camp has a good argument for analytics. The connected-model camp has a good argument for execution. Neither has a good argument for both. And revenue teams need both: accurate analysis of what happened yesterday and real-time response to what's happening right now.
There's a third option that neither camp talks about enough. Build the operational data model inside the application itself, so analytics and execution query the same tables. No ETL. No replication lag. No schema translation. This is the approach that actually works for revenue teams, and the architectural reasoning explains why.
Camp one: the centralized warehouse
The warehouse argument is appealing. You've got data in Salesforce, Gong, Outreach, ZoomInfo, Marketo, and Zendesk. Each tool has its own schema, its own definition of "account," and its own update cadence. Instead of trying to query six databases, you pipe everything into Snowflake, apply dbt transformations, and build your analytics on a unified layer.
For historical analysis, this works well. You can answer questions like "what was our average deal velocity in Q1 by segment?" or "which sequences produced the highest reply rates last quarter?" Warehouses are optimized for exactly this kind of aggregated, retrospective query. The SQL is flexible. The compute scales. The data is there.
The problem starts when you try to use warehouse data for operational decisions. A warehouse that syncs from Salesforce every 15 minutes is always at least 15 minutes behind reality. Many warehouse architectures sync hourly or daily. For a VP reviewing quarterly trends, an hour-old snapshot is fine. For a rep who needs to know whether the champion just opened the proposal, it's useless.
The typical warehouse-backed revenue stack has four layers of latency. Source system to staging (5-60 min via Fivetran or Airbyte). Staging to transformed model (dbt runs every 1-6 hours). Transformed model to BI tool cache (15-30 min). BI tool to user's screen (on-demand, but stale by definition). Total latency from event to visibility: 30 minutes to 8 hours. For a deal that needs intervention right now, that delay is the difference between saving it and losing it.
There's a second problem: warehouses are read-only. You can query a warehouse to find at-risk deals. You cannot update a deal stage, send an email, or create a task from the warehouse. Execution requires writing back to the source systems, which means another integration layer, another set of API calls, and another set of failure modes. The warehouse knows what's wrong. It can't fix anything.
Cost is the third concern. Snowflake and BigQuery charge for compute. Running complex queries across millions of rows of revenue data costs real money. A mid-market company spending $2,000-5,000/month on warehouse compute for revenue analytics is common. That's on top of the ETL tool costs (Fivetran: $1,000-3,000/month), the transformation layer (dbt Cloud: $500-1,500/month), and the BI tool (Looker or Tableau: $70-100/user/month). The total "warehouse stack" for revenue analytics easily reaches $5,000-15,000/month before you add the people to maintain it.
Camp two: connected data models
The connected-model camp took a different approach. Instead of centralizing data, keep it in the source systems but create shared identifiers and event streams that link records across tools. An account in Salesforce, a company in Gong, and an organization in Outreach all get mapped to the same canonical ID. Events flow through a message bus (Kafka, RabbitMQ, or a simpler webhook layer) so that when something happens in one system, other systems know about it.
This approach preserves real-time signals. When a call ends in Gong, the event triggers a pipeline update in Salesforce and a sequence adjustment in Outreach within seconds, not hours. The data stays fresh because there's no batch ETL process introducing lag.
The problem is schema reconciliation. Salesforce's "Opportunity" has 80+ fields. Gong's "Deal" has 30 fields. Outreach's "Prospect" maps to Salesforce's "Contact" but uses different field names and different data types. Getting these schemas to agree on what an "account" is, what a "deal stage" means, and how "close date" is formatted requires a mapping layer that somebody has to build and maintain. That mapping layer is a full-time job for a senior RevOps engineer, and it breaks every time one of the source systems changes its API or adds a field.
Salesforce makes an average of 3 major API changes per year. Gong and Outreach each make 4-6. A connected model that maps across all three faces 10-15 potential breaking changes per year. Each one requires an engineer to investigate, update the mapping, test the downstream effects, and deploy the fix. Most teams don't have dedicated staff for this. The mappings drift, data starts disagree across systems, and within 6 months nobody trusts any single number because each tool shows something different.
Connected models also struggle with complex queries. Asking "show me all deals where call sentiment was negative AND email engagement dropped below 10% AND the account's support tickets increased in the last 30 days" requires joining data from three different systems in real time. Even with shared identifiers, this join happens at the application layer, which means writing custom code or using an orchestration tool. Every new cross-system query is a development project.
The third option: operational data models
Both camps assume that revenue data naturally lives in multiple systems. The warehouse camp accepts this and aggregates after the fact. The connected-model camp accepts this and synchronizes in real time. Neither questions the premise.
What if the data lived in one system to begin with?
An operational data model puts all revenue-relevant data in a single database with a unified schema. Contacts, accounts, deals, activities, calls, emails, sequences, proposals, support tickets, commissions, and forecasts share the same tables, the same foreign keys, and the same timestamp format. There's nothing to ETL because there's one source. There's nothing to synchronize because there's one schema. There's no latency because the AI and the application query the same operational database.
This isn't a new idea in software engineering. It's how most SaaS products work internally. Shopify doesn't ETL its order data to a warehouse before showing merchants their dashboard. Stripe doesn't synchronize payment data across three systems before calculating MRR. The application and the analytics read from the same database. Revenue technology has been the exception because the market evolved around point solutions, each with its own data store.
Two things changed. First, databases got fast enough. Postgres with proper indexing handles analytical queries on millions of rows without needing a separate columnar warehouse. Second, AI changed what "complete data" means. Five years ago, having all your data in one system required building 30+ features natively. That was a 5-year, 50-engineer project. With AI-assisted development and modern frameworks, a small team can build a complete revenue platform in 18 months. The cost of building everything natively dropped below the cost of integrating everything together.
What an operational data model enables for AI
The architecture choice matters most when you add AI to the equation. AI-ready data is a competitive moat precisely because AI performance is bounded by data completeness and freshness.
When AI queries a warehouse, it gets stale data. A forecast model running on hour-old pipeline data can't account for the call that just ended 10 minutes ago where the buyer said "we're going with a competitor." The model produces a confident forecast number that's already wrong.
When AI queries connected models, it gets inconsistent data. The deal stage in Salesforce says "Negotiation." The call sentiment from Gong says "Negative." The sequence in Outreach is still running as if the deal is in "Discovery." The AI has to reconcile three conflicting versions of reality before it can produce a recommendation. Most AI models aren't built for this. They either ignore the conflicts or produce recommendations that reflect the average of the conflicting signals, which is worse than picking any single signal.
When AI queries an operational database, it gets complete, current, consistent data. The deal is in Negotiation. The last call was 10 minutes ago, sentiment was negative, and the buyer mentioned a competing vendor. The email sequence paused automatically when the deal moved to Negotiation. The proposal was viewed twice yesterday. The support team resolved a ticket this morning. All of this is in the same database, queryable in a single SQL statement, with no joins across systems and no stale caches.
This is the architecture that makes MCP (Model Context Protocol) work properly. The AI's context window gets filled with real data, not data that was real 4 hours ago. The recommendations it produces are grounded in what's happening now, not what the warehouse thinks happened earlier today.
In a warehouse architecture, the query "show me all deals where the last call had negative sentiment and the proposal hasn't been viewed" requires joining data from the CRM warehouse table, the call analytics warehouse table, and the deal room warehouse table. Each join introduces latency and potential data mismatches. In an operational data model, it's a single query against related tables in one database. The query runs in milliseconds, not seconds. And the results are current as of right now, not as of the last sync.
The trade-offs are real
An operational data model isn't free. Building 33 capabilities natively instead of integrating 12 best-of-breed tools is a significant engineering investment. The platform has to be good enough at each capability that teams don't miss their point solutions. A mediocre built-in call intelligence feature that misses half the insights is worse than Gong with a 15-minute sync delay.
The scale ceiling is also a consideration. A single Postgres database serving both application queries and analytical workloads will hit performance limits at some point. For revenue teams of 10-200 users handling thousands of deals, this isn't a problem. For a 10,000-person enterprise running millions of transactions, you'd need to shard or add a read replica for heavy analytics. The architecture handles the mid-market well and requires additional infrastructure at true enterprise scale.
The migration cost matters too. Moving from Salesforce + Gong + Outreach + ZoomInfo to a single platform isn't a weekend project. Data migration, workflow recreation, team training, and habit changes take 30-90 days depending on complexity. The long-term payoff in data quality, AI performance, and reduced tool cost is substantial, but the short-term switching cost is real.
Revian's architecture choice
Revian is built on a single Supabase (Postgres) database with 150+ migrations defining the complete schema. Every capability, from CRM and pipeline to call intelligence, proposals, and commissions, reads and writes to the same operational database. The AI assistant queries this database directly through 119 tools across 18 categories. Row Level Security (RLS) ensures every query is scoped to the requesting organization. A full audit trail logs every mutation, AI-initiated or human-initiated.
This architecture means a forecast query that factors in call sentiment, email engagement, proposal views, and deal stage progression runs against live operational data. No ETL job needs to complete first. No webhook needs to fire. No integration needs to sync. The data is there because the actions that created it happened in the same system.
The RevOps debate between warehouses and connected models is the wrong debate. Both approaches start from the assumption that revenue data will be scattered across many systems and ask how best to reassemble it. The better question is: what if the data was never scattered in the first place? For revenue teams that adopt an operational data model, the entire category of data infrastructure problems, the ETL pipelines, the sync delays, the schema mismatches, the stale AI inputs, simply doesn't exist. The data is already where it needs to be.
One database. All your revenue data. Zero ETL.
See what happens when AI queries live operational data instead of yesterday's warehouse snapshot.
Request Access