Apache Camel is an open source integration platform.
N/A
Matillion
Score 8.5 out of 10
N/A
Matillion is a data pipeline platform used to build and manage pipelines. Matillion empowers data teams with no-code and AI capabilities to be more productive, integrating data wherever it lives and delivering data that’s ready for AI and analytics.
$2.50
Pay as you go per user
SSIS
Score 7.6 out of 10
N/A
Microsoft's SQL Server Integration Services (SSIS) is a data integration solution.
N/A
Pricing
Apache Camel
Matillion
SQL Server Integration Services (SSIS)
Editions & Modules
No answers on this topic
Developer: For Individuals
$2.50/credit
Pay as you go per user
Basic
$1000
per month 500 prepaid credits (additional credits: $2.18/credit)
Advanced
$2000
per month 750 prepaid credits (additional credits: $2.73/credit)
Enterprise
Request a Quote
No answers on this topic
Offerings
Pricing Offerings
Apache Camel
Matillion
SSIS
Free Trial
No
Yes
No
Free/Freemium Version
No
No
No
Premium Consulting/Integration Services
No
Yes
No
Entry-level Setup Fee
No setup fee
No setup fee
No setup fee
Additional Details
—
Billed directly via cloud marketplace on an hourly basis, with annual subscriptions available depending on the customer's cloud data warehouse provider.
SQL Server Integration Services (SSIS) is built around the Microsoft ecosystem; we needed something that was either "ecosystem-agnostic" or focused on AWS, which Matillion is. SSIS has very limited ability to parameterize jobs/packages compared to Matillion, reducing the …
We selected Matillion primarily because of it's ability to connect to numerous data sources and easily create transformation jobs. While Fivetran does a better job managing and examining deltas, it is not easy to use and is very non user friendly. SSIS was not a good fit for …
The only other ETL tool I've used was SSIS. At first I thought Matillion seemed "kiddish" after using the polished Microsoft tool but now I think Matillion is easier and can do much more as it has so many built-in connectors etc. We selected Matillion at our job because of …
The Matillion selection was not my decision. But I think it's a good enough choice. It is especially valuable that the team can learn Matillion easily and that the project can be understood by the entire team with the visual environment instead of complex ETLs.
Matillion was chosen by Schibsted due to the seamless integration with Snowflake. The ease of use and fast workflow have made it an essential tool in our setup, and with the option to integrate nearly every data source there is, plus the ease of use, it really gives a lot of …
Matillion is much easier to set up and easier to work for the team. Offers a lot more connections which are easier to set up. Environment variables make it easy to set up once and job creation is easy. We use Metadata tables to just loop through the list of tables that need to …
Matillion is cloud-native, therefore it doesn't need virtual machines to set up. It is easier to use compared with some of them. It always does query pushdown, while other ones don't'. It is integrated with Snowflake, while other ETLs need to use workarounds in order to perform …
Similar simple GUI but Matillion's is much cleaner, easier to manage and debug, and easier to connect to cloud databases. Matillion is also much faster.
Overall from an ease of use and set up standpoint, it stacks up better than most of the other tools I've used. However, Matillion doesn't quite expand and scale up as well as the other solutions.
Matillion ease of use and feature set along with integration capabilities and built in integrations are definitely a step ahead than the other tools and it provides the ability for us ti integrate with refshift, Snowflake and on premise data sources and hence becomes a …
Matillion is much easier to use than the other tools that I've worked with in the past and has a more complete forward-thinking cloud strategy. Legacy ETL tools struggle to make use of modern cloud data warehouse patterns.
Being a fairly new player in the market, Matillion is coming up against some well-established names such as Pentaho and Talend. The primary benefit for our use case was the fact that Matillion is built specifically for Amazon Redshift. While Pentaho and Talend are more mature …
When looking to evaluate different options, we looked first to the experience and software we had in-house that would accomplish the job. When assessing alternatives outside we were looking for the tool that would offer the most flexibility.
Message brokering across different systems, with transactionality and the ability to have fine tuned control over what happens using Java (or other languages), instead of a heavy, proprietary languages. One situation that it doesn't fit very well (as far as I have experienced) is when your workflow requires significant data mapping. While possible when using Java tooling, some other visual data mapping tools in other integration frameworks are easier to work with.
Great: Need to query simpler APIs, or utilize well known services such as GSheets etc.? Matillion has got some of the best and easiest to use connectors out there. Not so great: Do you need have a competent CI/CD flow that you will be able to update / compare from Matillion as well as other sources at the same time? Good luck, you will need to be extra careful, as you might have to have a deeper dive into your servers Terminal each time you have a git conflict.
As I mentioned earlier SQL Server Integration Services is suitable if you want to manage data from different applications. It really helps in fetching the data and generating reports. Its automation make it very easy and time efficient. It works well with large database as well. But it doesn't work well with real time data, it will take some time to gather the real time data. I would not recommend using it in a real time/fast-paced environment.
Camel has an easy learning curve. It is fairly well documented and there are about 5-6 books on Camel.
There is a large user group and blogs devoted to all things Camel and the developers of Camel provide quick answers and have also been very quick to patch Camel, when bugs are reported.
Camel integrates well with well known frameworks like Spring, and other middleware products like Apache Karaf and Servicemix.
There are over 150 components for the Camel framework that help integrate with diverse software platforms.
Matillion is brilliant at importing data -- it would be amazing to have more ways to export data, from emailed exports to API pushes.
Any Python that takes more than a few lines of code requires an external server to run it. It would be great to have more integration (perhaps in a connected virtual environment) to easily integrate customized code.
Troubleshooting server logs requires quite a bit of technical expertise. More human readable detailed error handling would be greatly appreciated.
Connection managers for online data sources can be tricky to configure.
Performance tuning is an art form and trialing different data flow task options can be cumbersome. SSIS can do a better job of providing performance data including historical for monitoring.
Mapping destination using OLE DB command is difficult as destination columns are unnamed.
Excel or flat file connections are limited by version and type.
With the current experience of Matillion, we are likely to renew with the current feature option but will also look for improvement in various areas including scalability and dependability. 1. Connectors: It offers various connectors option but isn't full proof which we will be looking forward as we grow. 2. Scalability: As usage increase, we want Matillion system to be more stable.
Some features should be revised or improved, some tools (using it with Visual Studio) of the toolbox should be less schematic and somewhat more flexible. Using for example, the CSV data import is still very old-fashioned and if the data format changes it requires a bit of manual labor to accept the new data structure
We are able to bring on new resources and teach them how to use Matillion without having to invest a significant amount of time. We prefer looking for resources with any type of ETL skill-set and feel that they can learn Matillion without problem. In addition, the prebuilt objects cover more than 95% of our use cases and we do not have to build much from scratch.
SSIS is a great tool for most ETL needs. It has the 90% (or more) use cases covered and even in many of the use cases where it is not ideal SSIS can be extended via a .NET language to do the job well in a supportable way for almost any performance workload.
SQL Server Integration Services performance is dependent directly upon the resources provided to the system. In our environment, we allocated 6 nodes of 4 CPUs, 64GB each, running in parallel. Unfortunately, we had to ramp-up to such a robust environment to get the performance to where we needed it. Most of the reports are completed in a reasonable timeframe. However, in the case of slow running reports, it is often difficult if not impossible to cancel the report without killing the report instance or stopping the service.
Overall, I've found Matillion to be responsive and considerate. I feel like they value us as a customer even when I know they have customers who spend more on the product than we do. That speaks to a motive higher than money. They want to make a good product and a good experience for their customers. If I have any complaint, it's that support sometimes feels community-oriented. It isn't always immediately clear to me that my support requests are going to a support engineer and not to the community at large. Usually, though, after a bit of conversation, it's clear that Matillion is watching and responding. And responses are generally quick in coming.
The support, when necessary, is excellent. But beyond that, it is very rarely necessary because the user community is so large, vibrant and knowledgable, a simple Google query or forum question can answer almost everything you want to know. You can also get prewritten script tasks with a variety of functionality that saves a lot of time.
The implementation may be different in each case, it is important to properly analyze all the existing infrastructure to understand the kind of work needed, the type of software used and the compatibility between these, the features that you want to exploit, to understand what is possible and which ones require integration with third-party tools
If you are looking for a Java-based open source low cost equivalent to webMethods or Azure Logic Apps, Apache Camel is an excellent choice as it is mature and widely deployed, and included in many vendored Java application servers too such as Redhat JBoss EAP. Apache Camel is lacking on the GUI tooling side compared to commercial products such as webMethods or Azure Logic Apps.
Fivetran offers a managed service and pre-configured schemas/models for data loading, which means much less administrative work for initial setup and ongoing maintenance. But it comes at a much higher price tag. So, knowing where your sweet spot is in the build vs. buy spectrum is essential to deciding which tool fits better. For the transformation part, dbt is purely (SQL-) code-based. So, it is mainly whether your developers prefer a GUI or code-based approach.
I think SQL Server Integration Services is better suited for on-premises data movement and ADF is more suited for the cloud. Though ADF has more connectors, SQL Server Integration Services is more robust and has better functionality just because it has been around much longer
We're using Matillion on EC2 instances, and we have about 20 projects for our clients in the same instance. Sometimes, we're struggling to manage schedules for all projects because thread management is not visible, and we can't see the process at the instance level.
Very fast time to market in that so many components are available to use immediately.
Error handling mechanisms and patterns of practice are robust and easy to use which in turn has made our application more robust from the start, so fewer bugs.
However, testing and debugging routes is more challenging than working is standard Java so that takes more time (less time than writing the components from scratch).
Most people don't know Camel coming in and many junior developers find it overwhelming and are not enthusiastic to learn it. So finding people that want to develop/maintain it is a challenge.
Without this, we would have to manually update a spreadsheet of our SQL Server inventory
We would also have poor alerting; if an instance was down we wouldn't know until it was reported by a user
We only have one other person who uses SQL Server Integration Services , he's the expert. It would fall to me without him and I would not enjoy being responsible for it.
