4 ms·

this might be valuable technology, but as far as i can from reading the OP and from a look through the repo, this is not ETL--despite the fact that "ETL" is in

this might be valuable technology, but as far as i can from reading the OP and from a look through the repo, this is not ETL--despite the fact that "ETL" is in blog post's title, despite the fact that the technology is described there as "a fully managed ETL service", and despite the fact that the term is used over a dozen times in the short blog post. As everyone here knows, ETL is "extract transform load"; this technology is directed to a portion of the first of those three, "extact", and indeed" only a portion because the sole (?) focus seems to be on providing various connectors for data access from various sources, but Stitch doesn't for instance, provide a query language API so that you can write a single query that works across multiple data sour es. granted, i think providing a library of connectors for many diverse, data sources--eg, SalesForce CRM, Google Analytics, MySQL--is valuable, but it's not ETL, it's not even "E", just part of it. What's more the functionality Stitch does have is, in my experience, far from the most difficult or time-consuming component to build, instead, "Transform" is.

cm 10y ago
It's accurate to say that we're more focused on the extraction and loading parts of ETL. In our experience, almost all useful data analysis requires data to be transformed at multiple stages - for example, once to cleanse and normalize the data, and again to aggregate it. Our goal is to leave the data in the rawest form possible without losing accuracy or precision, so that further transformation can occur, likely using SQL. We recognize this isn't perfect for every use case, but our customers love it for getting rapid access to data that would otherwise be locked away in SaaS applications and transactional databases.