Amazon Web Services (AWS) may make lots (and lots) of money selling relational database services, but that hasn’t stopped Amazon CEO Jeff Bezos from using his annual shareholder letter to call out its inherent deficiencies in the modern world of big data. Apparently the company’s “specialized databases for specialized workloads” strategy involves providing just enough relational database technology to service RDBMS huggers while pointing to a bigger, brighter future with non-relational databases.
SEE: Amazon Web Services: An insider’s guide (free PDF) (TechRepublic)
They say that breaking up is hard to do
Relational databases may be legacy, but they seem to be a legacy that can’t easily be shaken. Hence, while Bezos proclaimed “companies felt constrained by their commercial database options and had been unhappy with their database providers for decades” because relational databases were “expensive, proprietary, have high-lock-in and punitive licensing terms,” it’s still true that those customers were unhappy for… decades. Even Amazon, eager to get out from under Oracle’s thumb and move off the database giant’s products, kept spending upwards of $50 million each quarter on Oracle for years as it sought to break free.
Even as it wriggled 97% free by the end of 2018, however, AWS stuck with relational database technology for much of its operations, moving much of those Oracle workloads to Amazon Aurora, a fully-managed MySQL and PostgreSQL-compatible service. It’s not hard to see why. As Gartner analyst Merv Adrian once put it, “The greatest force in legacy databases is inertia.”
In other words, the same rules apply to AWS as to the rank-and-file Global 5000 enterprises whose “broad familiarity with relational databases…made this technology the go-to even when it wasn’t ideal.” If the relational database workload ain’t broke, don’t fix it.
Back to the future
And yet “fix it” is exactly what AWS proposes for enterprises to do. No, not all at once, but AWS is hoping that developers will stop trying to fit square workload pegs into round RDBMS holes. Here’s where AWS’ “specialized databases for specialized workloads” starts to make a lot of sense, according to Bezos, especially as data outgrows the constraints that an RDBMS imposes:
Though sub-optimal, the data set sizes were often small enough and the acceptable query latencies long enough that you could make it work. But today, many applications are storing very large amounts of data – terabytes and petabytes. And the requirements for apps have changed. Modern applications are driving the need for low latencies, real-time processing, and the ability to process millions of requests per second. It’s not just key-value stores like DynamoDB, but also in-memory databases like Amazon ElastiCache, time series databases like Amazon Timestream, and ledger solutions like Amazon Quantum Ledger Database – the right tool for the right job saves money and gets your product to market faster.
It seems to be making a dent in the database market, according to Gartner analyst Merv Adrian. As the overall database market jumped back into double-digit growth in 2018, he said, AWS and Microsoft accounted for 73% of that growth, even as old-school vendors like Oracle and IBM consistently lost share. Cloud is a “massive” disruption, Adrian went on to say, because “In addition to functional and architectural disruption, it’s changing pricing, support, release frequency, and user skills and organizational models.” All of these factors contribute to the slow retirement of the old guard.
But not yet the retirement of relational databases, with “yet” being the operative term. While much of the database market’s growth comes from enterprises moving workloads to the cloud, and not necessarily to non-relational cloud databases, over time, according to Bezos, cloud and non-relational go together, because the cloud more naturally begets higher volumes and variety of data. That’s good for AWS (plus Microsoft, Google, and the Chinese cloud vendors), but it’s also good for customers who won’t have to continue shoving their data into the rows and columns of relational databases.