Read this eGuide to discover the fundamental differences between iPaaS and dPaaS and how the innovative approach of dPaaS gets to the heart of today’s most pressing integration problems, brought to you in partnership with Liaison.
There are good reasons for the hype around Amazon Redshift. Redshift is blazing fast and not that much more expensive than MySQL or PostgreSQL, the traditional mainstay of data engineers. But is Amazon Redshift really becoming predominant in the world of analytic databases, taking over its smaller siblings (like MySQL) as an analytics backend?
It would be glib not to concede that MySQL is designed for online transaction processing (OLTP), and the comparison is apples to oranges. However, for those who have been in the trenches, the story of “exploiting” MySQL as an analytic database must sound all too familiar: With a combination of intelligent schema design and sharding, many data engineering teams have built not-so-enterprise, poor man’s data warehouses atop MySQL and PostgreSQL.
While this solution costs a fraction of a similar solution using Teradata or Oracle, it is far from free: It is expensive to maintain and scale any data infrastructure because of the cost of the people managing it. Enter Redshift. By paying a bit of money to Amazon, Redshift customers can run the same queries faster and with much less maintenance. Is Amazon Redshift therefore a no-brainer?
Our own data paints a more nuanced picture, however. Because Treasure Data’s service fills the data lake/data refinery gap between event data and data warehouses, we can track which structured data stores our customers output data to: MySQL, PostgreSQL, Redshift, or Tableau Server, to name a few. In Treasure Data’s lingo, we’re looking at Result Output.
The most popular Result Output is not Redshift, as one might expect.