What is our primary use case?
We wanted to enable change data capture in our data lake from an Oracle database source, and BryteFlow Data Integration proved to be the cheapest alternative to enable change data capture.
Our main use case involves moving data from one place to another, specifically from a database to a data warehouse. Enabling BryteFlow Data Integration was fast enough. There are certain specific cases when your source is on-premises and your data lake is on the cloud, where decisions must be made about whether to place BryteFlow Data Integration on-premises or on the cloud, and what the differences are. We went through all of that analysis, and placing BryteFlow Data Integration closest to our source was the best solution.
What is most valuable?
BryteFlow Data Integration proved to be straightforward in implementation. We implemented it and enabled all the prerequisites on the database, and BryteFlow Data Integration itself was then able to enable change data capture on the database. Based on those changes, we were able to model our dimensions on our data lake. Since BryteFlow Data Integration is a platform as a service, it is straightforward; you just enable it and it starts working.
BryteFlow Data Integration positively impacts our organization by reducing the time we require to ingest change data capture data. Otherwise, we would have needed either a more expensive CDC solution or to build an in-house CDC solution, both of which would have cost us more in terms of time or money. BryteFlow Data Integration fits in well in the middle; it did not cost us too much and did not take us too long.
What needs improvement?
The features of BryteFlow Data Integration are fairly limited. It is an easy interface to be placed for change data capture on top of a database. The suite that I saw or the license that I had was fairly limited, but it gets the job done, which is what matters, and it is cheap.
The simplicity of the easy interface for change data capture stood out to me. For speed, BryteFlow Data Integration still needs improvement. If there is a lag in the connection or in the network connectivity, they need to work on faster selection or API-based programmatic access control. BryteFlow Data Integration itself needs to work on their documentation; I believe the documentation is very limited. Everything should be fine in terms of ease, but speed is definitely lacking when it comes to BryteFlow Data Integration.
BryteFlow Data Integration needs better documentation, better programmatic access, and a better, faster user interface. It needs to be more feature-rich; right now it is limited between sources and destinations. If there was a software as a service version of BryteFlow Data Integration where you could choose on the user interface what you are doing and implement that, it would be easier. Currently, we have to set up the exact tool for CDC or Blend or data flow separately and manage all of these solutions.
The support needs improvement as well.
For how long have I used the solution?
I have used BryteFlow Data Integration for CDC for about two years.
What do I think about the stability of the solution?
BryteFlow Data Integration is more or less stable. The licensing pattern within data integration is annoying, but if you have an ops team or an L1 team continuously monitoring the license, it is fine. If there is an outage lasting over four hours, everything goes down and requires a lot of rebuilding. I would not call it the most stable platform, but it does the job.
What do I think about the scalability of the solution?
The scalability of BryteFlow Data Integration is poor.
How are customer service and support?
The customer support is not the best.
Which solution did I use previously and why did I switch?
We did not use a different solution previously. We examined a few solutions, but based on ease of implementation and cost, we went with BryteFlow Data Integration.
How was the initial setup?
The simplicity of the easy interface for change data capture stood out during the setup. For speed, BryteFlow Data Integration still needs improvement. If there is a lag in the connection or in the network connectivity, they need to work on faster selection or API-based programmatic access control.
What about the implementation team?
Pricing, setup cost, and licensing were handled by our procurement team. All I know is that it was cheaper and easier to set up.
What was our ROI?
I can provide a qualitative answer to the return on investment question, though I would not have any metrics. It was the cheapest option available. We saved a lot of time during the setup because it was easier. I alone could administer everything, and a very small team of data engineers were able to build pipelines on top of it. BryteFlow Data Integration is an easy and cheap option.
What's my experience with pricing, setup cost, and licensing?
Pricing, setup cost, and licensing were handled by our procurement team. All I know is that it was cheaper and easier to set up.
Which other solutions did I evaluate?
We evaluated building a CDC setup ourselves based on Amazon EMR and Python coding that we could do on top of it. On the database, that was not an easy task to handle. We also considered Confluent, but they were too expensive, so we stuck with BryteFlow Data Integration.
What other advice do I have?
My advice for others looking into using BryteFlow Data Integration is that if they have the competency and the time to build an open-source solution on top of Debezium or Kafka or Kinesis, they should go ahead and do that.
If not, and they want to go for a SaaS solution, they should do that. BryteFlow Data Integration sits somewhere in the middle; it is not too difficult, not too expensive, but it is not the best product either. I would rate this product a 6 out of 10.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
