CData Sync Enterprise - CDC Replication for Cloud and On-Prem Data

The major use case I have for CData Sync is towards the ETL part. The way it works can be summarized in two sentences. Earlier ETLs required that you map a field manually, and if you had any new field, you had to manually adapt it. With CData Sync, this process is automated. If you have a new field, it updates the schema structure and adds that attribute automatically. If you have additional fields, whether you have one, two, three, or four, it goes ahead, updates that particular schema, and maps the data to that field automatically. It is such a time-saver in the ETL domain because previously we had to find out which particular mapping needed updating, and then go into those mappings to adapt them. With CData Sync, you do not have to do anything like that. You only have to update the source to indicate that it now has extra attributes, and the tool takes care of the rest.

Regarding the data transformation features during synchronization in CData Sync, I assess them as follows. As I mentioned, we were going ahead and manually doing updates wherever we needed transformation. For example, if my data is coming with names in lower cases but I have to put them into camel case or a title case format, that is something I have to apply manually. Otherwise, if it is a pass-through, the tool takes care of itself.

The drag-and-drop interface of CData helps to set up data workflows. I would say it is almost similar to other ETL tools which I have used. At the tool configuration level where you do not have to code much, it is almost similar in terms of familiarity. However, it has good features in that you do not have to do certain things manually.

The detailed logging and monitoring features are helpful for troubleshooting. Logging captures where it was updated, when it was updated, and who updated the source. When something fails because of transformation or other issues, you are able to get that information. Length is never an issue and data type is never an issue because the tool takes the data type from whatever is in the source. Unless that data type is not present in the target table, then you have an option to make it a default as string because then it takes everything. With that approach, it is actually quite good.

Change Data Capture operates on the schema level. If you have a schema change, whether it is a delta or a full load, it takes care of the target system. It changes your schema automatically, maps that particular field to the newly added field, and puts the data through that field itself. Those features are quite excellent.

In the area of improvements, within 20 days I would say that if there were a feature where I could add the transformation upfront itself, that would be great. For example, if my source is coming in a certain format and in XYZ target one I need it to be transformed with a lookup onto another table, if I could update that way with a platform staging approach where I am creating the tables into CData itself before sending it to the target, it would be excellent. That way I would not have to go into mappings; I would just have to update one particular source where I would create these platform staging tables. Right now, we can do it in an alternate way, but if the tool could give us that option directly, then it would be great. If not, it is still a great tool.

I have been dealing with this particular project product for around 20 days and it is super easy because I am using it in a freelancing project. Over there, I am consulting and developing this particular part in my area. CData Sync is a good tool.

Regarding the stability of CData Sync, I was happy with how stable it is. Whatever data I was working with, it was stable. However, I do not know how it would behave if the records or the data becomes a lot, because at the moment it was behaving quite well.

Regarding the scalability of CData Sync, my assessment is that it scales well. On the scalability terms, I can say one thing which I am sure of: if you have to scale it to multiple different source systems to the targets, it is scaling with that. Whether it is one object or whether it is 10 attributes, it takes it as changed data, updates the target accordingly, and you are good.

Concerning technical support, I have not had experience with them. It has only been 20 days, and there is nothing which we discussed because the knowledge base for CData was enough for us to get things done.

In terms of return on investment, I would say if you have to pay less to develop, you are saving money and that is your return on investment. Regarding pricing, I have a little bit of an idea of how much a company goes ahead and puts it to the customers. Normally, my rates to the customer become almost 2X what my company gives it to me. With that piece, if they have to pay 10 days less for me, that is 10 to 12% of development effort which they are saving.

When I compare CData Sync with other ETL tools, I would say it stands out in its own category. You do not have to manually put that particular mapping into the target to indicate that a field is new. CData Sync is the only tool which I know of that does it automatically. Whereas if I talk about PowerCenter, IDQ, Talent, or anything like that, you have to go manually into each mapping to update the target system.

CData Sync helps to manage my resource loads. Not just with source load, but also towards speeding up things in development where I have to go ahead and update the target structure, update the mapping, and all those particular pieces because that is already being taken care of by CData Sync. Not for us because our right now job is to create manual reports to push it, as it is an ad hoc request what we are doing right now. As the tool is fairly new, we are taking it a little bit slow and are not going ahead and automating it at the moment. I have not utilized the scheduling feature. I would rate this product a 7 out of 10.