Debezium + Kafka VS Rivery

Debezium started within Red Hat following the release of Kafka, and Kafka Connect. It was inspired in part by Martin Kleppmann’s presentations on CDC and turning the database inside out.

Debezium is the open-source option for general-purpose replication, and it does many things right for replication, from scaling to incremental snapshots (make sure you use DDD-3 and not whole snapshotting). If you are committed to open source, have the specialized resources needed, and need to build your own pipeline infrastructure for scalability or other reasons, Debezium is a great choice.

Otherwise, think twice about using Debezium because it will be a big investment in specialized data engineering and admin resources. While the core CDC connectors are solid, you will need to build the rest of your data pipeline including:

• The many non-CDC source connectors you will eventually need. You can leverage all the Kafka Connect-based connectors to over 100 different sources and destinations. But they have a long list of limits (see confluent docs on limits).
• Data schema management and evolution - while the Kafka Schema Registry does support message-level schema evolution, the number of limitations on destinations and the translation from sources to message makes this much harder to manage.
• Kafka does not save your data indefinitely. There is no replay/backfilling service that manages previous snapshots and allows you to reuse them, or do time travel. You will need to build those services.
• Backfilling and CDC happens on the same topic. So if you need to redo a snapshot, all destinations will get it. If you want to change this behavior you need to have separate source connectors and topics for each destination, which adds costs and source loads.
• You will need to maintain your Kafka cluster(s), which is no small task.

If you are already invested in Kafka as your backbone, it does make good sense to evaluate Debezium.

• Real-Time CDC: Kafka + Debezium captures database changes in real-time.
• Flexibility: Debezium supports multiple databases and allows for flexible configuration options for filtering and handling database changes.
• Scalable Data Streams: Kafka’s distributed architecture ensures that even high-velocity data streams are processed efficiently and can scale horizontally.

• Complex Setup: Managing a self-hosted Kafka cluster alongside Debezium requires significant operational effort, including scaling, monitoring, and ensuring fault tolerance.
• At-Least-Once Delivery: Debezium guarantees at-least-once delivery, meaning duplicate records may need to be handled at the consumer level. This adds complexity to building exactly-once data pipelines.
• High Infrastructure Costs: Running a Kafka cluster and Debezium connectors, especially at scale, can require substantial infrastructure resources, making it more costly than other CDC alternatives.

Kafka itself is open-source and free to use, but the costs associated with deploying and maintaining a Kafka cluster can vary depending on cloud or on-premise infrastructure. Managed Kafka services such as Confluent Cloud can provide a more streamlined, albeit pricier, solution. Debezium is open-source, but operational costs come from the Kafka infrastructure and any associated storage, processing, and egress costs.

Rivery was founded in 2019. Since then it has grown to 100 people and 350+ customers. It’s a multi-tenant public cloud SaaS ELT platform. It has some ETL features, including inline Python transforms and reverse ETL. It supports workflows and can also load multiple destinations.

But Rivery is also similar to batch ELT. There are a few cases where Rivery is real-time at the source, such as with CDC, which is its own implementation. But even in that case it ends up being batch because it extracts to files and uses Kafka for file streaming to destinations which are then loaded in minimum intervals of 60, 15, and 5 minutes for the starter, professional, and enterprise plans.

If you’re looking for some ETL features and are OK with a public cloud-only option, Rivery is an option. It is less expensive than many ETL vendors, and also less expensive than Fivetran. But its pricing is medium-high for an ELT vendor.

Rivery's future offerings, policies, and pricing may be uncertain as they undergo an acquisition with Boomi.

• Modern data pipelines: Rivery is the one other modern data pipeline platform in this comparison along with Estuary.
• Transforms: You have an option of running Python (ETL) or SQL (ELT). You do need to make sure you use destination-specific SQL.
• Orchestration: Rivery lets you build workflows graphically.
• Reverse ETL: Rivery also supports reverse ETL.
• Load options: Rivery supports soft deletes (append only) and several update-in-place options including switch-merge (to merge updates from an existing table and switch), delete-merge (to delete older versions of rows), and a regular merge.
• Costs: Rivery is lower cost compared to other ETL vendors and Fivetran, though it is still higher than several ELT vendors.

• Batch only: While Rivery does extract from its CDC sources in real-time, which is the best approach, it does not support messaging sources or destinations, and only loads destinations in minimum intervals of 60 (Starter), 15 (Professional), or 5 (Enterprise) minutes.
• Data warehouse focus: While Rivery supports Postgres, Azure SQL, email, cloud storage, and a few other non data warehouse destinations, Rivery’s focus is data warehousing. It doesn’t support the other use cases as well.
• Public SaaS: Rivery is public cloud only. There is no private cloud or self-hosted option.
• Limited schema evolution: Rivery had good schema evolution support for its database sources. But the vast majority of its connectors are API-based, and those do not have good schema evolution support.

Rivery charges per credit, which is $0.75 for Starter, $1.25 for Professional, and negotiated for Enterprise. You pay 1 credit per 100MB of moved data from databases, and 1 credit per API call. There is no charge for connectors. If you have low data volumes this will work well. But by the time you’re moving 20GB per month it starts to get more expensive than some others.

Estuary is a managed data integration platform for CDC, streaming, and batch pipelines. It supports database CDC, SaaS and API ingestion, event streams, files, warehouses, data lakes, operational systems, and AI destinations, with delivery ranging from real-time streaming to scheduled batch intervals.

At the center of Estuary is its runtime, where captured data is written to durable collections and can be independently read by multiple destinations and transformations. This separates source capture from downstream delivery and allows data to be reused for additional destinations, backfills, and reprocessing without repeatedly extracting it from the source.

Estuary offers 200+ fully managed connectors, no-code capture and materialization setup through the web application, and streaming transformations using SQL, Python, and TypeScript. It also supports dbt Cloud, materialization triggers, Agent Skills for AI-assisted pipeline development, and Public, Private, and Bring Your Own Cloud (BYOC) deployment options.

• CDC, streaming, and batch in one platform: Estuary supports log-based CDC, SaaS and API ingestion, event streams, files, and scheduled batch movement for analytical and operational use cases.
• Real-time runtime with durable collections: Estuary's runtime separates captures from materializations through durable collections, allowing data to be reused for multiple destinations, transformations, backfills, and replay without re-extracting it from the source.
• Low-latency delivery: Supported real-time pipelines can deliver data with sub-second latency, while delivery can also be scheduled when lower freshness is sufficient.
• No-code setup with advanced transformation options: Pipelines can be configured through the web application, while SQL, Python, and TypeScript transformations, dbt Cloud, APIs, and flowctl support more advanced workflows.
• Built-in monitoring and AI-assisted operations: Estuary includes logs, latency and usage metrics, pipeline alerts, OpenMetrics integrations, and Agent Skills for AI-assisted pipeline development and troubleshooting.
• Flexible deployment and predictable pricing: Public, Private, and BYOC deployments provide different levels of infrastructure control, while pricing is based on data volume and prorated connector task hours rather than Monthly Active Rows.

• Smaller managed connector catalog than some large ELT platforms: Estuary offers 200+ fully managed connectors, but some larger platforms have broader packaged coverage, particularly for long-tail SaaS and legacy enterprise applications. Custom connector development is available with Enterprise.
• No visual transformation canvas: Pipeline setup is no-code, and fields can be selected or renamed in the UI, but more complex streaming transformations use SQL, Python, or TypeScript rather than a drag-and-drop transformation canvas.
• Advanced workflows have a learning curve: Basic capture and materialization pipelines can be built through the web application, but advanced derivations, schemas, CLI workflows, and GitOps-style deployments require more data engineering familiarity. Some Estuary users on G2 also mention a learning curve for more advanced configurations.

Estuary pricing is based on data volume moved and connector instance usage. Data movement is priced at $0.50 per GB. The first six connector instances are priced at $100 per month each, while additional connector instances are $50 per month each, with usage prorated based on active connector instances.

The permanent free tier includes up to 10 GB of data movement per month and two concurrent connector instances, while the 30-day trial provides access to the full Cloud plan.

Enterprise plans can include volume discounts, Private or BYOC deployments, custom SLAs, private networking, dedicated support, and custom connector development.

Because pricing is based on GB moved plus connector usage rather than row-change metrics such as MAR, costs are relatively predictable from data volume and connector usage.