Salesforce CDC Architecture for Data Warehouses
Updated: 3 days ago
Salesforce Change Data Capture (CDC) architecture publishes every record modification — creations, updates, deletions, and undeletes — as a discrete event the moment it happens, so a warehouse applies it within seconds rather than waiting on the next scheduled query. Pushing only the delta instead of re-pulling an entire object is what makes Salesforce data warehouse integration fast and light on API consumption, and this guide breaks down how the architecture works, where it earns its keep, and how to design the warehouse side without tripping governor limits.
What Salesforce Change Data Capture Actually Does
Salesforce Change Data Capture sits on top of the platform event bus. Enabling it on a standard or custom object means Salesforce emits a change event every time a record is created, updated, deleted, or undeleted, with a header describing which fields changed and in which transaction. A subscriber — your integration layer, a middleware tool, or a custom Apex trigger — listens on that channel and reacts immediately, instead of running a query on a fixed timer and hoping nothing changed in the gap.
That subscription model is the core of event-driven replication: the system captures state changes as they occur and sends them downstream as discrete events, rather than recomputing an entire dataset. Engineering teams historically solved database synchronization with polling scripts that compared timestamps and hoped nothing slipped through the cracks between runs. CDC replaces that guesswork with a built-in guarantee. For orgs running Salesforce data synchronization at scale, this distinction matters far more than it looks on paper, because a nightly batch job that pulls two million Account records to catch four thousand changes wastes API calls, compute capacity, and engineering time that an event stream simply doesn't require.
Why Event-Driven Replication Reduces API Pressure
Every Salesforce org runs against API request limits tied to its edition and total user count. A full-object SOQL query against a large table eats a meaningful share of that budget each time it runs, so firing it hourly against dozens of objects means the org burns through its daily allocation fast, often before the workday has properly begun.
Change Data Capture inverts that cost structure. Because the platform pushes only the records that actually changed, the integration stops re-querying data that hasn't moved, and that reduction is the essence of API limit management: instead of scheduling frequent full-table pulls and hoping the org avoids throttling, a subscriber connects once and lets the event stream carry the load. Fewer redundant calls also means fewer retries, fewer rate-limit errors during peak business hours, and more predictable performance for every other integration sharing the same org.
Building a CDC-to-Warehouse Architecture: A Step-by-Step Framework
1. Enable Change Data Capture on the Objects That Matter
Turn on CDC selectively across Accounts, Opportunities, Cases, and whichever custom objects the reporting layer truly depends on, rather than across every object in the org, since each enabled object adds directly to the event volume the platform generates and therefore deserves careful scoping against actual warehouse needs.
2. Subscribe to the Event Channel
Connect a subscriber to the change event channel using the Pub/Sub API or a CometD client, and build it to handle reconnects gracefully, since a dropped connection during a burst of changes is where most CDC pipelines lose data if engineers haven't planned for recovery.
3. Land Events in a Staging Layer First
Write incoming events to a staging table or topic before applying them against the production warehouse schema, since a staging layer creates a checkpoint for deduplication, for reordering events that arrived out of sequence, and for replaying a batch whenever a downstream job fails partway through.
4. Apply Changes with Upsert Logic, Not Overwrites
Merge each incoming event into the warehouse using the record ID as the match key, updating only the changed fields while preserving relational integrity between parent and child objects, and treat a delete event as an instruction to soft-delete or archive the row rather than silently discarding history that reporting or audits might need later.
5. Track Replay IDs to Handle Gaps
Salesforce retains change events only for a limited replay window, and every event carries a replay ID that a well-built subscriber checkpoints on the fly. A subscriber that goes offline needs to resume from its last processed replay ID rather than restarting from zero, or a short, otherwise unremarkable outage quietly turns into a full resync.
6. Decide How Much of This You Want to Build and Maintain
Everything described above is achievable with native tooling and custom code, but it also amounts to a real, ongoing engineering commitment, since reconnect logic, schema drift handling, and constant monitoring all need someone actively watching them, which is precisely where a managed replication layer earns its place, a point the next section develops further.
CDC vs. Batch Salesforce ETL vs. Real-Time Replication
Not every warehouse sync requirement demands event-level latency, so it helps to be clear about which pattern fits which use case before committing engineering resources to it.
Batch Salesforce ETL — a nightly or hourly job that extracts, transforms, and loads full or filtered datasets on a fixed schedule — remains the simplest pattern to build and reason about, but its latency is measured in hours, and every run re-touches data that may not have changed since the last one, which is exactly the tradeoff it makes for simplicity.
Incremental data replication narrows that gap by tracking a last-modified timestamp and pulling only the records touched since the previous run, and that's a real step up over full extracts, but it still depends on a query schedule, so a record changed twice between runs surfaces only once, and the warehouse is never truly more current than its last poll.
CDC-driven, event-based synchronization closes the remaining distance: modifications appear in the warehouse close to the moment they happen inside Salesforce, without a query schedule imposing an artificial floor on data freshness. For teams whose reporting or live dashboards cannot tolerate stale data, that pattern is truly worth architecting around, and it's usually a layered decision rather than an all-or-nothing commitment, since plenty of production setups run near-real-time sync for a handful of genuinely high-value objects while relying on incremental batch Salesforce ETL for the long tail of reference data that rarely changes.
Where Sesame Software Fits Into a CDC-Driven Warehouse Strategy
Native Change Data Capture solves only the event side of the equation, telling a team what changed and precisely when, but it doesn't solve schema management, warehouse-side merge logic, ongoing monitoring, or the real engineering hours it takes to keep a custom subscriber running reliably in production, and that gap is exactly what Sesame Software closes.
Sesame Software's replication engine syncs Salesforce data directly into a data warehouse — Snowflake, Redshift, SQL Server, PostgreSQL, and other major destinations — as frequently as every five minutes, or in true real time for selected objects through its Real-Time Option (RTO), without custom Apex triggers, middleware code, or a subscriber engineering has to babysit. Schema changes on the Salesforce side propagate automatically, parent-child relationships stay intact on the warehouse side, and no data ever sits on Sesame's own servers in between, since it travels directly from Salesforce into infrastructure the organization fully controls. That combination is what solid salesforce data integration looks like in practice: real low latency, without hand-built event plumbing sitting underneath it.
For a mid-market or enterprise IT team already stretched thin across a dozen competing priorities, that combination is the practical, deployable version of CDC architecture. Backed by 30+ years building enterprise data infrastructure, 15 patents underlying its replication technology, and SOC 2 Type II certification, Sesame Software backs that architecture with the track record regulated IT teams reasonably expect. And because downtime and data loss carry real cost — enterprise downtime runs an average of $9,000 per minute, while the average data breach costs firms $4.45M — a sync layer that's fast, controlled, and audit-ready stops being a nice-to-have and becomes a genuine necessity.
Ready to see what a low-latency, no-code data warehouse integration looks like within your own Salesforce environment? Talk to a Data Expert.
Frequently Asked Questions
What are the tools helpful for Salesforce data warehouse integration?
The right toolset depends on how much custom engineering a team wants to own, and native options include the Salesforce Bulk API, SOQL-based extracts, and the CDC event bus for teams building their own subscriber, while managed replication platforms — Sesame Software among them — handle the connection, schema mapping, and sync logic so the IT team configures a job instead of maintaining a pipeline.
What is data synchronization?
Data synchronization is the ongoing process of keeping two or more systems' data consistent with each other as changes occur in either place, and in a Salesforce context, that usually means pushing changes made inside the CRM out to a warehouse, a BI tool, or a downstream app, on a schedule tight enough that both sides truly reflect the same reality.
What is EDW (enterprise data warehouse)?
An EDW is a central repository that pulls data from multiple source systems — Salesforce, ERP platforms, support tools, and more — into one structure built for reporting rather than day-to-day transactions. Salesforce CDC architecture feeds an EDW nonstop, keeping that copy current without full re-extracts.
What is real-time data synchronization?
Real-time data synchronization moves changes from a source system to a target system the instant they happen, rather than on a batch schedule, and Salesforce CDC event streams achieve this natively, while a replication platform with a true real-time option gets there another way, which is why many teams combine both approaches on purpose.
What is data sync, and how does it differ from a one-time migration?
Data sync is an ongoing process that keeps systems aligned over time, whereas a migration is a one-time move of data from one system into another, and a CDC-based architecture is built for sync, meant to run for good rather than finish a task and shut off.
Related Resources
