There's something to be said for familiarity - I work in a Postgres shop now, but spent years operating large MySQL clusters in prior jobs. I'm learning Postgres, but still way more intimately familiar with MySQL (and in particular, InnoDB) internals and would probably reach for it for any new project I were architecting on my own.
Major relational databases generally all do the same stuff in similar ways for the 80% use cases, but when you get into the 20% of weird edge cases, operational concerns at scale, and troubleshooting... really knowing the storage engine internals like the back of your hand is useful.
They probably use MySQL for Basecamp and it's worked for them so they're also using it for Hey (same team developing both). As for Vitess it makes sense since it's made to work nice with Kubernetes (which they are using). I don't know of a Postgres equivalent.
Yes but I feel Vitess is much more widely used than Citus. MySQL community, last time I check has formed a more mature ecosystem and conscious on HA and Clustering.
Postgres still feels more like throwing you a bunch of options and you are on your own.
It is not that a solution being more widely used means it is good, you are just less likely running into edge cases with no help at all.
Basecamp (and 37 Signals) has been a MySQL shop forever, so I'm sure they have a ton of operational experience with it. There is no reason for them to switch to Postgres at this point, for much of the same reasons a place like GitHub is still on MySQL.
Changing database engines with large, established apps has a _huge_ cost and is usually not worth it.
MySQL 8 is very solid and has resolved the vast majority of the gripes of the past. Postgres is, as always, amazing software, but MySQL is no longer the choice to be shunned.
I don't know if I could go back to not having transactional DDL, partial and function-defined indexes, non-blocking ("concurrent") indexing, and so on...
I'm not sure where I suggested "Hey, long time Postgres users, you should switch to MySQL!". The point is it's a solid modern database and a completely fine option in 2020.
MySQL8 supports functional indexes and concurrent indexing fyi. It still does not have transactional DDL nor partial indexes.
I've used them (via Postgres) to build large database-backed web applications (like Hey), realtime bidding systems (100mm+ records, 250,000+ requests/sec), and so on over the last 10+ years. Recursive CTEs as well, and MySQL finally has those as of a year or two ago. The feature gap is closing, but it's been a very, very slow process.
Is there a MySQL Roadmap somewhere? I cant seems to google anything up. Compared to Postgres which seems have way more information.
And Postgres still hasn't caught up to MySQL in multi / clustering solution. Or may be they dont ever intend to focus on it and leave it to third party.
Not that I'm aware of no. While the end product is released open-source, the development cycle itself is very much closed-source and there are very valid concerns about MySQL being owned by Oracle. MariaDB is a fully open-source alternative though I'd argue MySQL8 has surpassed MariaDB in terms of quality and features.
Probably in-house expertise and experience running previous services. That usually (or should at least) outweighs feature set in selection process, especially for databases.
I interpret it as "I didn't think about it, picked the first thing that worked in the past, and don't wish to make an argument about it, so let it go".
I think he means that if you use Postgres you are more likely to also be an evangelist for it. That doesn't tend to happen on the Mysql side. You don't hear people saying "you should switch from postgres to mysql" but you hear plenty of the opposite. Mysql works fine for most things and so that's what he used.
Now that I've thought about it more, it makes more sense. When used properly, Rails handles a bunch of the stuff that would make Postgres a better choice (like data validation, constraints, etc.)
Major relational databases generally all do the same stuff in similar ways for the 80% use cases, but when you get into the 20% of weird edge cases, operational concerns at scale, and troubleshooting... really knowing the storage engine internals like the back of your hand is useful.