Change Data Capture tells you what already happened to a record. Platform Events let you announce anything you want, in whatever shape you want, whether a record changed or not. That's the whole decision in one sentence: CDC is automatic and record-bound, Platform Events are custom and free-form. Everything else is detail.
Both ship data out of Salesforce through the same pipe: the Streaming API, consumed by CometD clients, external subscribers, or other Salesforce orgs. Both support near-real-time delivery. Both get stored in an event bus with a retention window. Past that surface similarity, they're built for different jobs, and picking the wrong one means either fighting the platform or building something fragile.
Change Data Capture watches standard and custom objects you've enabled and publishes an event every time a record is created, updated, deleted, or undeleted. You don't write the payload. Salesforce writes it for you, using the record's fields plus a header that tells you the change type and the transaction it came from.
This makes CDC the right tool when your downstream system just needs to mirror Salesforce data. A data warehouse that wants every Account change. A search index that needs to stay in sync with Contacts. A middleware layer replicating Opportunity updates into a legacy ERP. You're not modeling a business process here. You're replicating state.
CDC events also carry field-level change info, so a subscriber can tell exactly which fields changed in an update, not just that something changed. That's useful when you want to avoid processing a record every time an unrelated field gets touched by some unrelated automation.
Platform Events are custom objects you define yourself, with your own fields, published explicitly from Apex, Flow, or an external system through the REST or Bulk API. Nothing happens automatically. You decide when an event fires and what it contains.
This matters because a lot of real business events aren't record changes at all. A payment gateway confirms a charge. A warehouse system marks an order as shipped. A user clicks a button to request approval. None of that is a DML operation on a Salesforce object, so CDC has nothing to capture. Platform Events exist precisely for this gap: they let you broadcast something that happened, independent of whether a record was touched.
Platform Events also work in the other direction. External systems can publish events into Salesforce, and Apex triggers or Flows can subscribe and react. CDC is one-way, out of Salesforce. Platform Events are bidirectional by design.
CDC answers: did this record change, and how? Platform Events answer: did something happen that the business cares about? Those are different questions even when the answer involves the same record.
Say a support case gets escalated. CDC will tell a subscriber that the Case record's Status field changed from New to Escalated. A Platform Event called Case_Escalated can tell a subscriber that, plus the reason code, the SLA tier, the agent who escalated it, and a priority score computed by a Flow, none of which exist as fields on the Case object. CDC gives you the fact. Platform Events give you the fact plus context you had to build.
If your integration logic is just: whenever X changes, send it somewhere, CDC is less code and zero maintenance overhead on the publishing side. If your integration logic needs business meaning attached to the moment, Platform Events are the only option, because CDC can't invent fields that don't exist on the record.
CDC is enabled per object in Setup, no code required to start publishing. Platform Events require you to define the event object, its fields, and the publish call in Apex or Flow, which is more setup but gives you total control over payload size and shape.
Retention differs too. Standard-volume Platform Events and CDC events both retain for 72 hours by default. High-volume Platform Events can extend that, but you pay for it in your event allocation. Either way, a subscriber that's down for four days has already lost history and needs a replay strategy, not a shrug.
| Factor | Change Data Capture | Platform Events |
|---|---|---|
| Payload source | Automatic, from record fields | Custom, defined by you |
| Trigger | Any DML on enabled object | Explicit publish call |
| Direction | Outbound only | Bidirectional |
| Setup effort | Low, point-and-click | Higher, requires schema and code |
| Best for | Data replication, sync | Business process signals |
The mistake teams make most often: using CDC to try to signal a business process, then bolting on a second layer of logic downstream to reinterpret field changes as meaning. That second layer is fragile. It breaks the moment someone adds a new way to reach the same field value, because CDC only tells you what changed, not why. If you find yourself writing a subscriber that parses field diffs to guess at intent, you needed a Platform Event, not CDC.
The opposite mistake happens too: teams build custom Platform Events to replicate basic record sync, reinventing field-by-field change payloads that CDC already produces for free. That's wasted engineering effort and an extra object to maintain for no benefit.
Both consume your org's daily event allocation, measured in 24-hour rolling windows, and both can hit delivery delays under heavy load. CDC volume scales with how much data changes in your org, which you don't fully control. Platform Event volume scales with how often you choose to publish, which you do control.
That control is an advantage during design. You can throttle, batch, or filter before publishing a custom event. You can't tell CDC to publish less often for a noisy object without disabling it entirely, which also kills the signal you might actually need from that object elsewhere.
Ask one question: am I syncing data, or am I signaling an event? If the answer is syncing data, and the fields you need already live on the record, use Change Data Capture. Setup is faster, maintenance is close to zero, and Salesforce keeps the payload correct as the schema evolves.
If the answer involves logic, computed values, external system state, or anything that isn't a plain field on a Salesforce object, build a Platform Event. Yes, it's more work up front. That work is what makes the event actually mean something instead of making a downstream system guess.
Plenty of real architectures use both. CDC keeps a search index or data lake in sync with core objects. Platform Events carry the handful of business-critical moments, like order confirmations or escalations, that need extra context and sometimes need to flow back into Salesforce. Treating them as interchangeable is where integrations start rotting within a year.
Yes, and most mature Salesforce integrations use both. CDC typically handles bulk data replication for objects that need to stay in sync elsewhere, while Platform Events carry specific business signals that need custom payloads or need to flow back into Salesforce. They run on the same event bus infrastructure without conflicting.
Yes. You can enable CDC on both standard objects like Account and Opportunity and on any custom object in your org, as long as it's included in your org's CDC allocation limits. Setup happens in Setup under Change Data Capture, where you simply select the objects you want to track.
Both CDC and standard-volume Platform Events retain data for 72 hours by default, so any subscriber offline longer than that loses those events permanently unless you've configured extended retention for high-volume events. Subscribers need a replay ID strategy to resume from the correct point once they reconnect, not just a reconnect-and-hope approach.
No, both use the same Streaming API infrastructure and deliver in near-real-time under normal load. Delivery speed depends more on overall event bus volume and subscriber processing capacity than on which event type you're using. Heavy spikes in either can cause delays regardless of the mechanism.
Platform Events require you to explicitly build a trigger on the event object to react to incoming events; nothing fires automatically just because an event was published. This is different from CDC, where enabling the feature is enough to start generating events, though you still need a subscriber to act on them. Both approaches need a dedicated subscriber or trigger to actually do something with the data.