> damn near impossible for most MySQL users.

MySQL? Nobody, and I mean NOBOBY is saying you should use MySQL. All of the things you mention is trivial using a decent SQL solution like PostgreSQL.

Except the person to whom I replied said to use traditional SQL databases:

> Traditional SQL databases end up being many times simpler in practice, and because of their inherent scaling limitations, much easier to manage. And most importantly: their implementations aren't buggy.

They mean traditional SQL databases like PostgreSQL, SQL Server, DB2, Oracle etc.

Not MySQL. MySQL has almost none of the important features of a real SQL database management system. Nobody should be using MySQL for anything.

Quick, tell YouTube and Facebook they’ve been doing it wrong all along

They are NOT using stock-standard MySQL and haven't done so for many years. If you are big enough to make your own programming languages the normal rules do not apply.

And if you ask the Youtube team for a recommendation for your project, they will not point you to MySQL.

i haven't touched mysql in years but quite frankly, 99% of websites out there (blog/cms) will run fairly fine on a Mysql database. as for the other 1%, they would be big enough to pick the right db of their choice as the time comes. so there is no need to tell everyone you should be using this or that.

this is kind of like telling everyone that they should ALL be using emacs, when vim/nano is still sufficient for the job.

I honestly don't see a single reason why MySQL should be used over PostgreSQL for anything, thus my sweeping statement. I could be wrong but I don't think so.

You got downvoted, but I agree with you. Traditional RDBMS is inherently single-node and a pain to scale. The actual sad thing here is that there's no mature/reliable commodity (i.e. open source) distributed RDBMS for transaction processing yet.

I have to bring this up again: NewSQL. There are quite a few new choices out there, Google Spanner, Cockroachdb(https://github.com/cockroachdb/cockroach), TiDB (https://github.com/pingcap/tidb). All of them are very easy to scale while maintaining the ACID transactions.

I said open source and mature :)

IMO really the best option for distributed OLTP RDBMS/NewSQL right now is basically either Citus or Vitess, only because they are built on the backs of extremely mature databases. It really feels like all other options are not mature enough (except maybe VoltDB).

Could you please elaborate how you define "mature"?

IMO, in descending order of importance to me:

* Dependability. I can be completely certain that standard usage of the database won't lose my data or leave it in a bad state, at the very least.

* Community. There's an active IRC channel (or the like) where I can ask questions. When an error show up, I can Google it and easily find an applicable solution most of the time.

* Performance. Not just with synthetic (i.e. TPC-C, TPC-H, YCSB, etc.) workloads, but proven to have reasonably satisfactory QPS in many/most real production settings.

* Ecosystem. There's a good collection of first-party (and also ideally third-party) tools, constantly being improved. (Mere wire-compatibility with MySQL or Postgres might be good, but probably isn't enough, since 100% wire compatibility seems rare.)

Thanks for sharing！These criteria seems quite practical. You are probably right. Time will tell.

CockroachDB? I'll grant you it's still young, but it pretty solidly hits all your other checkboxes.

IMO, it's very promising but still extremely immature.

I still believe in Curt Monash's cardinal rule of RDBMS development: http://www.dbms2.com/2013/03/18/dbms-development-marklogic-h...

VoltDB?

Galera + HAProxy or ProxySQL should give you a multi-master MySQL with no app rewrites required, no?

Primary key conflicts are still a thing. Especially problematic where you're either not using auto_incrementing PKs, and/or you try to switch writes from one master to the other and app has to be aware of the switch.

Not using auto incrementing keys is surely a rarity with MySQL projects.

Even before galera was a thing regular MySQL replication could use auto_increment_(increment|offset) to make each server generate unique id's.

There exists a LOT of data models that don’t use auto incrementinf primary keys. Rarity or not, it’s a real use case and a real problem for master/master replication

Also, even if you do use auto increment with offsets for each server, you’ll have to know how many servers you’ll eventually have, or waste offsets and eventually risk outrunning your data types

Non auto keys will already need some way to ensure uniqueness that will involve the application expecting conflicts.

For those that do use auto inc, galera will manage the offset/increment value based on cluster size automatically.