I can second using Percona; I wasn't much of a believer in MySQL until I inherited a medium sized application using Percona 5.7. Once you get past a few of the initial warts (like making sure the database doesn't silently truncate your data--yuck), it's been really performant, stable and impressive (and we're running a setup with a fairly complex schema with master operating at ~3000 QPS average, a slave actively replicating for read load balancing and backup, and Sphinx for FTS).
Knowing what to be careful with on MySQL, I would certainly consider using the Percona flavor again in a new application.
I hit an in production bug with the silent truncation field thing the other day, old system (2009ish) that was been moved.
Table had a field that was varchar(128) and wasn't used (original filename but system generated a hashed filename and served it with that name (for sharding, lots of files)) so for 5 years MySQL had been silently killing everything > 128 characters and it didn't matter.
Then along comes our hero (me in this story) who does all the upgrades, tests everything thoroughly (he thought) and it's all fine, deploy, test everything fine.
Next morning, 9 bug reports "Can't upload files at all FIXITNOW!!!".
Turns out company was auto generating PDF's from some report software that dumped all the data into the filename and none of them where less than 128 chars.
MySQL 5.7 started not silently dumping data into the bitbucket in the sky and instead threw an error (when quite reasonably you tried to shove 300 characters into a varchar(128)).
TLDR: MySQL doing the right thing broke the broken.
Knowing what to be careful with on MySQL, I would certainly consider using the Percona flavor again in a new application.