> The only feature that Aurora (MySQL) has that is remotely impressive

Aurora is one of the only options if you need low-lag physical replication in a MySQL-compatible environment. That makes it operationally feasible to execute large/heavy writes or DDL which would normally cause too much replication lag on traditional (async binlog-based) MySQL replicas.

Granted, there's some important fine print: long transactions will still block InnoDB purge of old row versions, and in Aurora that's cluster-wide. But in any case, personally I'd consider nearly-lag-free replication to be an important differentiator. This can be leveraged in interesting ways, for example CashApp's `spirit` OSC tool (https://github.com/block/spirit) can do online schema changes blazing-fast because it doesn't need to throttle its write rate to avoid replication lag.

Scale-to-zero is also nice for dev/test environments.

That said, I do agree with your overall point that Aurora was majorly over-marketed. And Amazon's capture of so much revenue in the MySQL space has been extremely detrimental for the MySQL ecosystem, especially considering Aurora's modifications are proprietary/closed-source.

Re: lag, that’s a fair point, but IME devs don’t care if it’s 10 msec or 1000 msec, they don’t trust it either way. “I have to read after write.” I know MySQL doesn’t have RETURNING, maddeningly, but I’ve tried explaining how they could use LAST_INSERT_ID() to no avail.