Show HN: Ingestr CDC – open-source CDC replication in Go(bruin-data.github.io)
bruin-data.github.io
Show HN: Ingestr CDC – open-source CDC replication in Go
https://bruin-data.github.io/ingestr/getting-started/cdc.html
1 comments
Man I have had a lot of gripes with debezium... the setup alone in a kubernetes cluster with strimzi kafka connect... And dealing with the kafka connect errors and fixing replication slots... ehhh was painful. Does this tool make it any well easier.
One problem I expirienced in production systems with staging doubles is that sometimes we do database restores from production onto staging and that makes the sinks and sources go haywire... does ingestr handle this well?
Is support for kubernetes/helm anywhere in the pipeline
One problem I expirienced in production systems with staging doubles is that sometimes we do database restores from production onto staging and that makes the sinks and sources go haywire... does ingestr handle this well?
Is support for kubernetes/helm anywhere in the pipeline
İngestr is meant to be a lot more simpler to operate than Debezium and the likes of it, so yes, it makes things a lot easier.
About the staging dump, I haven't tried it but I don't see why it wouldn't work? I'll give it a try.
Yes, we'll create and share a helm chart, although we already publish Docker images so it should be trivial to spin up a chart if you wanted to.
About the staging dump, I haven't tried it but I don't see why it wouldn't work? I'll give it a try.
Yes, we'll create and share a helm chart, although we already publish Docker images so it should be trivial to spin up a chart if you wanted to.
ingestr is a CLI tool that can ingest data from 130+ sources. I have shared it on HN after our Go rewrite as well, which made it the fastest ingestion tool in the space. However, ingestr had always been a batch tool. I am personally a big fan of batch workloads due to their simplicity and have built ingestr around that assumption as well; however, over time, the cracks started to show when we started working with larger orgs.
Turns out there are some scenarios where CDC proves beneficial: - For legacy systems where it is not possible to introduce cursor columns due to technical, but mostly organizational, concerns, it becomes impractical to deploy batch pipelines. - For systems that do not have a way to reliably know the update timestamp, also due to legacy reasons. Think usecases where the columns are updated without the timestamp being updated. - For hard deletes.
Even though I do believe there are ways to solve each of these, it ended up putting us in a disadvantage, and we decided to build the CDC connectors instead.
ingestr CDC works in two modes now: batch (bad name, I know) and stream. The batch mode is reading the changelog entries from the last load until the starting timestamp, and the streaming mode keeps reading and landing them to the destination databases.
ingestr has a few advantages compared to a more traditional debezium + kafka setup: - it's a standalone Go binary and does not require any additional infra. - it has very low resource consumption, ~100MB baseline. - it can run on your own computer during development, and can be converted into a streaming prod deployment when it is ready. - supports 20+ destinations already, primarily analytical platforms like snowflake, databricks, generic iceberg destinations, etc.
i would love to hear any feedback on what we could do to make it easier for cdc workloads!
https://github.com/bruin-data/ingestr