When NOT to Use CDC (Change Data Capture)

Change Data Capture has become a popular pattern for data integration, real-time analytics, and event-driven architectures. The ability to track database changes and propagate them to downstream systems sounds universally beneficial. Yet CDC implementations frequently create more problems than they solve when applied inappropriately. Understanding when CDC is the wrong choice saves organizations from architectural debt, operational nightmares, and expensive refactoring projects.

This article explores the scenarios where CDC should be avoided, the red flags that signal you’re heading toward a CDC anti-pattern, and the alternative approaches that better serve specific use cases. By examining the limitations and failure modes of CDC, you’ll develop judgment about when this powerful pattern becomes a liability rather than an asset.

When Your Data Volume Doesn’t Justify the Complexity

CDC introduces significant architectural and operational complexity—change tracking mechanisms, log parsing infrastructure, state management, and failure recovery systems. This complexity only pays dividends when you’re dealing with substantial data volumes or update frequencies that make simpler approaches infeasible.

For databases receiving fewer than 1,000 updates per day, CDC is almost certainly overkill. A simple periodic query—running every few minutes or hourly—can replicate the same data movement with a fraction of the complexity. A batch job that queries WHERE updated_at > last_sync_timestamp accomplishes data synchronization without CDC infrastructure, log parsing, or complex failure handling. The overhead of running such queries on small databases is negligible, often completing in milliseconds.

Consider these simpler alternatives for low-volume scenarios:

• Scheduled batch queries: Use cron jobs or AWS EventBridge to query changed records periodically. For tables with proper indexing on timestamp columns, these queries execute efficiently even on millions of records. You avoid CDC’s streaming infrastructure while maintaining reasonable data freshness.
• Application-level change tracking: Have your application code explicitly publish events when it modifies data. This provides cleaner semantics than database-level CDC since your application understands business meaning. A user registration doesn’t just create a database row—it represents a business event your application can publish directly.
• Database triggers: For specific tables requiring immediate propagation, triggers can push changes to message queues or invoke webhooks. While triggers have their own maintenance overhead, they’re simpler than full CDC for targeted use cases involving just a few critical tables.

The break-even point where CDC complexity becomes justified typically occurs around 10,000-50,000 daily changes, depending on your latency requirements and operational maturity. Below this threshold, you’re implementing distributed systems complexity for a problem that batch processing solves adequately.

A small e-commerce site with 500 orders daily doesn’t need CDC to sync order data to a data warehouse. A nightly batch job extracts new orders, spending perhaps 5 seconds to identify and transfer changes. The resulting 12-24 hour latency suffices for business intelligence needs. Introducing CDC here adds streaming infrastructure, monitoring systems, and failure scenarios while delivering marginal benefit—analytics reports run on yesterday’s data either way.

When You Need Guaranteed Consistency and Transactions

CDC fundamentally breaks transactional guarantees that applications rely on. Database transactions ensure either all changes commit together or none do—inventory decrements, order creation, and payment processing succeed or fail atomically. CDC captures these changes as independent events, introducing temporal gaps where downstream systems observe partial transaction states.

This consistency problem manifests in subtle but serious ways. Consider an order management system where creating an order involves inserting into orders, order_items, and customer_notifications tables within a transaction. CDC captures each insert as a separate change event. Downstream systems consuming these events might process the orders insert before the order_items inserts, temporarily believing an order exists with zero items—a logically invalid state.

CDC consistency challenges become critical when:

• Cross-table relationships matter: If downstream systems need to see related changes together to maintain correctness, CDC’s row-by-row change streaming creates consistency windows where relationships appear broken. Financial systems calculating account balances from transactions across multiple tables cannot tolerate observing partial transactions.
• Order of operations affects correctness: CDC tools attempt to maintain operation order, but network delays, retries, and failures can reorder events. An application that inserts a record then updates it might have those changes arrive in reversed order downstream. Systems assuming insert-then-update sequences will fail catastrophically when updates arrive before inserts.
• Downstream systems make decisions based on data: If consumer systems use captured data to trigger actions—sending notifications, triggering workflows, updating inventory availability—consistency gaps cause incorrect decisions. Sending order confirmation emails before order items are captured results in incomplete confirmations.

Alternative approaches preserve transactional semantics better. The transactional outbox pattern writes both business data and event records within the same database transaction. A background process then reads the outbox table and publishes events, ensuring events only exist when the underlying transaction committed. This guarantees downstream systems never observe uncommitted or partial states.

For scenarios requiring strong consistency, synchronous APIs remain superior to CDC. Rather than capturing database changes and propagating them asynchronously, have systems communicate directly through API calls within transactional boundaries. When System A needs to inform System B about an event, it calls System B’s API before committing its transaction. If System B fails, the entire operation rolls back, maintaining consistency.

When Your Database Schema Changes Frequently

CDC implementations tightly couple to database schemas—table structures, column names, and data types. When schemas evolve, CDC configurations require updates, testing, and often code changes in consuming systems. Organizations with rapidly evolving schemas find CDC’s coupling creates constant maintenance overhead and deployment coordination challenges.

Schema evolution scenarios that break CDC include adding or removing columns, renaming tables or columns, changing data types, splitting or merging tables, and modifying primary key structures. Each change potentially breaks CDC configuration and downstream consumers expecting specific formats. A seemingly simple column rename propagates through CDC infrastructure, event schemas, consumer parsing logic, and data warehouse mappings.

The schema coupling problem intensifies when:

• You’re in early development stages: Startups and projects in discovery phases iterate rapidly on data models. Requirements change weekly as you learn about your domain. In these environments, CDC’s schema coupling creates friction at precisely the wrong time—when you need maximum flexibility to experiment with structures.
• You have many downstream consumers: Each consumer system depends on the event schema CDC produces. Schema changes require coordinating updates across all consumers simultaneously or implementing complex versioning schemes. With 10 consumer systems, a simple column addition becomes a coordination nightmare requiring 10 deployment updates.
• You lack schema registry infrastructure: Mature CDC implementations use schema registries (like Confluent Schema Registry) to version schemas and provide compatibility checking. Without this infrastructure, schema evolution becomes error-prone and manual. Small teams lacking resources to operate schema registries struggle with CDC schema management.

For schema-volatile environments, API-based integration provides better abstraction. APIs define contracts independent of underlying database schemas. Database structure can evolve freely as long as API contracts remain stable. You refactor database tables, split columns, or denormalize structures without affecting consumers—the API layer absorbs these changes.

Event-driven architectures with explicit event definitions also avoid CDC’s schema coupling. Instead of capturing raw database changes, applications publish domain events with well-defined schemas—OrderCreated, PaymentProcessed, ShipmentDispatched. These business events remain stable even when underlying database schemas change. An orders table might split into order_headers and order_details tables, but the OrderCreated event schema stays unchanged, insulating consumers from implementation details.

Consider the maintenance burden concretely. A team managing 5 tables with CDC that undergo schema changes monthly spends significant time updating CDC configurations, adjusting consumer code, and coordinating deployments. This same team using API-based integration updates the API implementation internally while maintaining contract stability, requiring consumer changes only when business requirements actually shift rather than with every internal refactoring.

When You’re Dealing with Sensitive Data and Compliance Requirements

CDC tools capture and stream all database changes, including sensitive personal information, financial data, and regulated content. This broad capture creates significant security and compliance challenges that organizations often underestimate when adopting CDC.

The fundamental problem is that CDC operates at the database layer, below business logic where access controls and data masking typically apply. A database user with CDC permissions sees everything, regardless of application-level authorization rules. An employee who shouldn’t access customer credit card data might not have application permissions but could access CDC streams containing that same data in raw form.

Compliance and security concerns that make CDC inappropriate:

• PII and GDPR requirements: CDC streams contain personal data flowing through multiple systems—log files, message queues, data lakes. Each storage location becomes a data processing point requiring GDPR compliance, retention policies, and deletion mechanisms. When users request data deletion (right to be forgotten), you must purge data not just from source databases but from CDC logs, message queues, backup streams, and all downstream stores—an often impossible task.
• Audit trail requirements: Regulated industries need detailed audit trails showing who accessed what data when. CDC stream consumers typically don’t generate such audit logs since they’re reading system-level change streams rather than making explicit data requests. Financial institutions needing SOX compliance or healthcare organizations requiring HIPAA audit logs find CDC’s lack of access attribution problematic.
• Data masking and field-level security: Applications often mask sensitive fields based on user roles—showing only last four digits of credit cards to customer service representatives. CDC captures unmasked data from the database, bypassing these controls. Implementing field-level masking in CDC pipelines is complex and error-prone, requiring duplication of business logic.
• Encryption and key management: CDC streams containing sensitive data require encryption in transit and at rest. Managing encryption keys, rotating them periodically, and ensuring only authorized systems decrypt data adds operational complexity. A compromised CDC pipeline exposes broad data access, unlike targeted API breaches limited to specific endpoints.

Alternative patterns provide better security boundaries. API-based data sharing applies authentication, authorization, and data masking at the API layer where business logic resides. Systems requesting customer data authenticate, receive only fields they’re authorized to access, and generate audit logs automatically. API rate limiting prevents bulk data extraction.

Event sourcing with privacy by design publishes domain events containing only necessary data. Instead of CDC capturing entire customer records, applications publish CustomerEmailUpdated events containing just the new email address and customer ID. Minimal data exposure limits compliance scope and reduces risk.

For organizations with sophisticated data governance, CDC can work—but requires significant additional infrastructure: field-level encryption, format-preserving encryption for searchable encrypted data, comprehensive audit logging, automated data lineage tracking, and retention management systems. The complexity makes CDC viable only for organizations with mature data governance practices and substantial engineering resources dedicated to compliance.

When Operational Complexity Exceeds Your Team’s Capacity

CDC implementations introduce distributed systems complexity requiring specialized expertise to operate reliably. Teams without experience managing streaming infrastructure, handling backpressure, debugging consistency issues, and operating 24/7 monitoring frequently struggle with CDC operational burden.

The operational challenges accumulate across multiple dimensions. CDC connectors interact with database internal logs (PostgreSQL’s WAL, MySQL’s binlog, Oracle’s redo logs), requiring deep database expertise to troubleshoot issues. Message streaming infrastructure like Kafka needs capacity planning, partition management, and retention tuning. Consumer applications require failure handling logic, idempotency guarantees, and state management. Monitoring must track lag, throughput, error rates, and data quality across the entire pipeline.

Operational complexity indicators suggesting CDC is premature:

• Small engineering teams: Teams with fewer than 5 engineers struggle to maintain CDC infrastructure alongside application development. CDC becomes a second full-time job—monitoring streams, investigating lag, updating connectors, handling schema changes. These teams benefit from simpler patterns requiring less operational overhead.
• Limited on-call resources: CDC failures often require immediate response—consumers falling behind, connectors crashing, database log retention causing data loss. Organizations without 24/7 on-call rotation or those where engineers handle on-call alongside many other responsibilities find CDC’s operational demands overwhelming.
• Lack of streaming expertise: CDC introduces Kafka, Kinesis, or similar streaming platforms that behave differently than traditional request-response systems. Teams inexperienced with streaming concepts like offset management, partition rebalancing, and exactly-once processing face steep learning curves. Initial enthusiasm for CDC often wanes when teams encounter production issues they can’t diagnose.
• No established monitoring and alerting: CDC requires sophisticated monitoring—lag metrics, consumer health, connector status, data loss detection, throughput tracking. Teams without existing observability infrastructure for streaming systems cannot effectively operate CDC. Building this monitoring infrastructure is a project in itself.

Consider a 3-person engineering team maintaining a moderate traffic SaaS application. Adding CDC for syncing data to a data warehouse seems straightforward initially. However, the operational reality includes: configuring and maintaining Debezium or similar CDC connectors, operating Kafka or managed alternatives, writing consumer applications with proper error handling, monitoring lag and investigating when consumers fall behind, handling schema changes across the pipeline, and responding to production incidents at night or on weekends.

This team could instead run a nightly batch job—a single SQL query wrapped in a Python script, scheduled with cron, monitored with simple email alerts on failure. When issues occur, they’re investigated during business hours. Schema changes are handled by updating a single query. Total operational burden: perhaps 2-3 hours monthly versus CDC’s 10-20 hours for ongoing maintenance plus urgent incident response.

Simpler integration patterns for operationally-constrained teams:

• Scheduled batch ETL: Run hourly or daily jobs extracting changed data. Modern databases handle these queries efficiently with proper indexing. Tools like Apache Airflow provide scheduling, monitoring, and retry logic without streaming complexity.
• Polling-based synchronization: Have downstream systems periodically poll source systems via APIs for updates. While less efficient than push-based CDC, polling requires minimal infrastructure and scales adequately for moderate throughput.
• Managed integration services: Platforms like Fivetran, Airbyte Cloud, or AWS Glue handle operational complexity for you. These managed services cost more per-unit-of-data than self-managed CDC but eliminate operational burden entirely—valuable when engineering time is your constraint.

The decision should factor your team’s growth trajectory. A 2-person team anticipating growth to 10+ engineers might accept initial CDC operational burden as investment in future scalability. A stable team of 5 with no growth plans should optimize for sustainable operational load rather than theoretical scalability.

When You Actually Need Business Events, Not Database Changes

CDC captures low-level database mutations—insert, update, delete operations on rows. These technical changes differ fundamentally from business events—meaningful occurrences in your domain like “customer placed order,” “payment was processed,” or “shipment was delivered.” Conflating database changes with business events leads to architectures that couple domain logic to database implementation details.

The distinction matters because database changes don’t cleanly map to business semantics. A single business event might generate multiple database changes—creating an order involves inserting into orders, order_items, customer_notifications, updating inventory, and inserting audit_logs. CDC produces 5+ separate change events, forcing consumers to reconstruct the business event from technical operations.

Worse, database changes reflect implementation details rather than business intent. An update to an order record might represent order cancellation, address correction, item quantity change, or status progression—fundamentally different business events from a domain perspective, indistinguishable in CDC streams showing only before/after row values. Consumers must infer intent by comparing field values and applying business logic—duplicating domain knowledge across systems.

Scenarios where business events are required instead of CDC:

• Event-driven microservices: Services communicating through domain events need business-level semantics. An inventory service doesn’t care that the orders table had an insert—it cares that an OrderPlaced event occurred, containing SKUs and quantities reserved. This semantic clarity enables services to react appropriately without understanding other services’ database schemas.
• CQRS and event sourcing: Architectures built on command-query responsibility segregation and event sourcing fundamentally require business events as the source of truth. CDC’s database change streams don’t provide the event history needed for event sourcing. These patterns need explicit event publishing, not database change capture.
• Complex business process automation: Workflow engines and process automation systems trigger on business events—loan application submitted, approval received, documents signed. Database-level changes don’t carry the business context these systems need. An update to an applications table’s status column doesn’t convey the business transition’s meaning.
• Cross-bounded-context communication: In domain-driven design, bounded contexts communicate through published language—explicitly defined business events. CDC creates implicit coupling through shared database schemas rather than intentional published contracts. This coupling undermines DDD’s goal of context independence.

The solution is explicit event publishing at the application layer. When your application processes an order, it publishes an OrderPlaced event to a message bus alongside database writes. This event contains business semantics—order total, customer ID, items purchased, promotional codes applied—structured for consumer understanding rather than reflecting database schema.

Application-level event publishing patterns:

• Direct event bus publishing: Application code publishes events directly to Kafka, RabbitMQ, or EventBridge after successful database transactions. While this risks event loss if publishing fails, it provides the cleanest separation between business logic and infrastructure.
• Transactional outbox: Insert events into an events table within the same transaction as business data. A separate process reads this table and publishes events, guaranteeing events only exist for committed transactions. This pattern combines transaction safety with eventual event publishing.
• Event sourcing: Store events as the primary record, deriving database state from event history. This inverts the typical relationship—events are truth, database is a projection. While architecturally sophisticated, this pattern provides perfect alignment between business events and system behavior.

Organizations adopting CDC “as a shortcut” to event-driven architecture inevitably regret it. CDC seems like a quick win—capture changes without modifying applications. Reality proves messier—consumers need business logic to interpret technical changes, schema coupling prevents independent evolution, and you’ve built infrastructure that doesn’t actually deliver business event semantics. Investing upfront in proper event publishing creates architectures that remain maintainable as complexity grows.

When Latency Requirements Don’t Match CDC Characteristics

CDC is often marketed as enabling “real-time” data replication, but actual latency characteristics vary dramatically based on implementation details and system load. Understanding CDC’s latency profile helps identify scenarios where it cannot meet requirements.

CDC latency encompasses multiple stages: database commit to log write, log parsing and event creation, event transmission through message infrastructure, consumer processing. Each stage adds delay—typically 100ms to several seconds total under normal conditions, expanding to minutes during system stress, network issues, or consumer lag.

For use cases demanding sub-100ms end-to-end latency, CDC fundamentally cannot deliver. High-frequency trading systems, real-time fraud detection, or interactive application features requiring immediate data visibility need synchronous patterns. If a user updates their profile and immediately views another page expecting to see updated information, CDC’s eventual consistency creates unacceptable user experience—they see stale data despite just making changes.

Latency scenarios inappropriate for CDC:

• Interactive user experiences: Features where users expect immediate feedback require synchronous data flows. After submitting a form, users expect confirmation and updated UI reflecting their changes instantly. CDC’s asynchronous nature creates delays users perceive as bugs.
• Dependent operations with tight timing: Processes where step B must begin within milliseconds of step A completing cannot rely on CDC. Financial transaction processing where authorization must immediately trigger risk checks needs direct coupling rather than eventual CDC propagation.
• High-frequency updates on same records: Tables receiving hundreds of updates per second on the same rows create CDC challenges. CDC tools capture each change separately, creating massive event volumes overwhelming consumers. Real-time dashboards aggregating metrics updated thousands of times per second need direct database queries or specialized time-series databases, not CDC.

Conversely, CDC’s latency characteristics work perfectly for many analytical and reporting use cases. Data warehouse synchronization running every few minutes provides sufficient freshness for business intelligence. Audit logging consumed hourly for compliance reporting handles CDC’s variability gracefully. Machine learning feature stores updated every 30 seconds tolerate CDC lag comfortably.

The key is honest evaluation of actual latency requirements versus perceived desires. Stakeholders often request “real-time” data when they actually mean “fresh enough to support good decisions”—which might be 5 minutes, 1 hour, or even daily for many business contexts. CDC serves the latter well while failing the former.

Conclusion

CDC represents a powerful pattern for specific scenarios—high-volume data replication, cross-system synchronization, and audit trails at scale. However, its complexity, consistency limitations, schema coupling, security implications, and operational demands make it unsuitable for many common integration needs. Organizations succeeding with CDC have substantial engineering resources, mature operational practices, appropriate use cases, and realistic expectations about its characteristics.

Before implementing CDC, honestly assess whether simpler alternatives serve your needs adequately. Most organizations benefit more from well-architected APIs, explicit event publishing, or periodic batch processing than from the distributed systems complexity CDC introduces. Choose CDC deliberately when its specific strengths match your requirements, not because it represents fashionable technology or seems like a shortcut to more fundamental architectural work.