Richie and I attended the AWS re:Invent conference in Vegas last week. Here’s some of my favorite takeaways about Amazon Aurora, their homegrown relational database with MySQL compatibility.
1. AWS has a grudge against Larry Ellison. Andy Jassy’s keynotes made repeated jokes about Oracle’s cloud product (or lack thereof), the high cost of proprietary databases, and expensive sailboat hobbies. Larry’s big, bold personality makes for an easy target, but I couldn’t help but wonder if AWS will come after SQL Server’s costs next.
2. Amazon’s database products are lucrative. Their database products are their fastest-growing products in history. The cynic in me suspects that they’re measuring growth in terms of revenue, not customer count, and since databases are expensive, voila.
3. Amazon’s Aurora product is ambitious. Aurora is their home-built relational database product. They manage backups, availability, and patching. In 2014, they announced full MySQL compatibility – you could point any MySQL app at Aurora, and it’d work just fine. This year, they announced PostgreSQL 9.6.1 compatibility, too.
4. Aurora PostgreSQL was 3 years in the making. That’s gotta make you wonder: are they trying to build SQL Server compatibility? Granted, it’d be a lot of work – it’s a closed source database. Feature compatibility would be an arms race: Microsoft would rapidly try to add features to entice users onto newer versions, while at the same time Amazon would have to race to keep up. (Hey, interesting coincidence – Microsoft’s been suddenly shoving features in – even in service packs.)
5. I’m guessing Aurora Oracle compatibility will come next. In the PostgreSQL announcement session, the speakers pointed out that PostgreSQL is the most Oracle-compatible database, with some 60-70% of applications being able to switch over. Theoretically, AWS could fund open source development of further Oracle compatibility, but given AWS’s lack of contributions back to open source projects, I wouldn’t bet on that. Instead, I’d bet on them doing something internally that only Aurora would offer.
Before going to re:Invent, I would have bet against AWS aiming for Oracle compatibility. However, during the keynotes, I kept hearing enterprise stories over and over. AWS really wants to be the default data center for enterprises, and enterprises run Oracle (and SQL Server of course).
Amazon won’t have an easy road. Their edge is that they’re essentially getting two database platforms for free: MySQL and PostgreSQL. Amazon has developers, sure, but they don’t have to build a query optimizer, for example. Thing is, those platforms aren’t Oracle.
6. Amazon’s throwing in free performance monitoring tools. The new Performance Insights tool shows wait stats, top resource-intensive queries, lock detection, execution plans, and 35 days of data retention. It’s designed by a former Oracle (there we go again) performance tuning consultant to match his workflow. You don’t have to install an agent, configure a repository, or keep the thing running. It’s in preview for Aurora PostgreSQL today, and will be rolled out to all RDS databases (including SQL Server) in 2017.
7. You don’t need to learn Aurora today. This isn’t going to be one of those doom-and-gloom posts that says, “The cloud is coming for your job!” The cool thing about Aurora is that it works just like the MySQL and PostgreSQL you
know and love don’t know anything about and aren’t particularly fond of – it just takes away the crappy parts of database administration, like backups, corruption checking, and HA/DR failovers.
If you were a MySQL or PostgreSQL query/index tuner, you could keep right on working in Aurora – only now, your skills relate in direct cost improvements. If you can tune queries and indexes well, you can cut your company’s cloud bill directly – and see the improvement in your very next bill.
The same thing will happen when Amazon comes for Oracle, and eventually, SQL Server. Your performance tuning skills will still work – and they’ll even be worth more.
As they say in Vegas, place your bets.