How is this a case of creating vendor lock-in at all? The service itself is API compatible with MySQL... you can migrate to... MySQL, MariaDB, or a host of other services that are exposed in a MySQL compatible interface.
It is vendor lockin because it means you avoid thinking about how to deal with scaling beyond the single box.
So when the moment comes and you want to move away from AWS and you have scaled well beyond the capacity of a single box, what then? Suddenly you have to figure out sharding, replication and HA setups from scratch. While that may be the right choice for you if you're an early stage startup and it lets you defer engineering costs until a point where you're hopefully better funded, it's also dangerous:
It's far easier to get things like sharding and caching and use of read-replicas and multi-master replication right if you think about it from the beginning (if you've ever tried to retrofit any of this onto an application not designed with it in mind you know what I'm am talking about). It'd be awesome not to have to worry about this, but if you don't, you tie yourself into a platform you'll find it harder and harder to move off.
As a product, this solution would be a killer - it sounds fantastic. As an AWS-only service, I for one will treat it as if it doesn't exist, because getting tied to AWS for the long term is not an option for most of the projects I do.
You can also do sharding on mysql, or use foundation, or any number of other platforms that are mysql compatible as I said... lock-in means that you don't have the ability to migrate relatively easily. In this case, your application layer likely wouldn't need to change at all.
They've even mentioned it's pretty much a click-through to migrate from mysql... to me that seems like the opposite of lock-in.
As to only being able to use their infrastructure to scale this way, that's a value-add.. that's part of why you pay for SaaS instead of developing your own infrastructure. This is why you're renting instead of buying.
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.
"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.
