There's nothing stopping you from using a scale-out architecture with Aurora, and nothing stopping you from running MySQL on your own hardware with loads of SSDs to get the throughput you are after.

Quote from article:

"Baseline storage performance is rapid, reliable and predictable—it scales linearly as you store more data, and allows you to burst to higher rates on occasion."

You mean to say that I can scale my single MySQL instance linearly with data storage by just throwing bigger SSDs at it? That has not been my experience, please share how you have been able to accomplish this?

Fair point, I don't know what voodoo they use, but you can purchase monstrously big servers (you'll need more than just one fit availability in any event) and storage arrays that would exceed the performance requirements of the vast majority of plausible use cases. The cost of such equipment is likely more expensive than AWS though.

The point is you can run MySQL or any of its variants on your own hardware or anyone else's. Nobody forces you to use Amazon's implementation.

Once you have scaled to beyond the performance available on a standard setup on a single box without preparing to scale out, you face increasing costs in a migration because you potentially have to re-engineer your app to be able to run on a very different stack.

Compatibility at the connection level is just one part of a whole lot of issues to take into account when considering whether or not you can migrate elsewhere easily.

Given how expensive AWS is, that's something to seriously consider.

Well if only AWS provides the scaling you need then what would you migrate off of AWS to? You could re-arch your app to scale out for some use cases as you suggest, but that's also an indicator that using AWS allowed you to get to market faster with a much simpler system that didn't require a far more complex design, many more engineering hours and more admin.

Aurora max looks like it's 64TB, that's 640 times larger, which I guess is what you're hinting at.

Your profile says you work at Google...

I certainly do. On cloud no less. The reality is that Amazon got to market several years before Google, so GCP had some catching up to do. That trend is changing, and this is one indication.

If you're going to post your subjective opinion on something involving your employer vs a competitor it's best to include a disclaimer in future.

What was the subjective opinion? "neat"? The rest was factual.

The subjective opinion was about "following" when Amazon has had relational database services for years, and the latest engine they say was under development for 3 years, not exactly something in response to goog.

Irrespective of that you shouldn't be posting as joe public when in fact you are a Google employee playing cheerleader for Google products on threads about your competitors products. Keep it classy.

We're not talking about a relational database, we're talking about a mysql-wire-compatible database. Google BigQuery has been around for a while too.

Adding "disclaimer: googler" to every post I make on HN seems pretty obnoxious to both me and anyone reading. I just didn't feel that "neat" + a fact qualified. Clearly opinions on that differ, and I'll probably just post less in the future.

It's only necessary in cases where there is an obvious conflict of interest.

That's fair. It's certainly not my intention to astroturf.

The interface is MySQL, no shortage of alternative implementations... Did Microsoft open source SQL Server?? How about the source code for ANY of their cloud services? They are ALL proprietary.

In his defence even googling GCP doesn't return that as a result on the first page. I was searching for the same thing.

GCP is largely used as the acronym for "Good Clinical Practice" and has been around a heck of a lot longer than Google.

Most acronyms (especially TLAs) get overloaded daily. Being first means next to nothing, in this space.

4 times faster than MySQL on the same platform, how did they pull that off?

Here is what they claim in the FAQ:

"Amazon Aurora delivers significant increases over MySQL performance by tightly integrating the database engine with an SSD-based virtualized storage layer purpose-built for database workloads, reducing writes to the storage system, minimizing lock contention and eliminating delays created by database process threads. Our tests with SysBench show that Amazon Aurora delivers over 500,000 SELECTs/sec and 100,000 updates/sec, five times higher than MySQL running the same benchmark on the same hardware."

I'd love to see more details (active benchmarking). At the very least, what is the CPU and disk utilization during the benchmark? It'll shed some light on how this was done: a 5x improvement in cycles per query? Or better caching?

People will benchmark this themselves ASAP. If you do, try to include some basic system metrics. The output of "vmstat 10", "iostat -x 10", and some "pidstat -t 1" would be a great start. This may only be possible for the MySQL benchmark, if Aurora is only visible via an API, and the database system can't be accessed directly (?).

To get the most comparable hardware setup for the comparison, I think you would want to run both Aurora and MySQL via RDS. RDS does not give you access to the underling EC2 instance, just to metrics via Cloudwatch.

Sounds to me like they are not using EBS like RDS-MySQL would be..

TokuDB claims to be 20x faster, so Amazon must be slacking. :-)

I don't vouch for any of these claims, but MySQL is certainly not the ultimate in DB performance.

Amazon's RDS MySQL already runs on SSD by default.

Yeah but we get hit by write/update contention constantly. :(

Would love to see if aurora fixes this for us.

SSD EBS most likely.