Does MySQL support CHECK constraints yet? Last time I used it it silently ignored them if they were in the DDL.
I have a pretty low opinion of it because of this.
* There is one for an identity column, which often ends up being similar `GENERATED BY DEFAULT AS IDENTITY` https://blog.2ndquadrant.com/postgresql-10-identity-columns/ https://dba.stackexchange.com/a/161356 and I don't believe mysql supports that syntax https://dev.mysql.com/doc/refman/5.7/en/create-table-generat...
Edit: forgot transactional ddls, real ones, not the ones mysql has in the pipeline.
Postgres is "harder" to use because when you make a dumb mistake it tells you about it.
This post is an oversimplification but summarizes my general impression.
What's terrible to you is a plus for Web 2.0 data storage - not everybody wants B&D just to insert a row or to select a timestamp.
I happen to use both databases, but I recommend MySQL first for startups.
Just stupid things like "This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'".
The query planner is crap and I've actually had it hang the instance.
The explain output is barely usable compared to postgres'.
Postgres supports a rich set of languages to write functions in.
Postgres supports rich set of column, row, and table access control.
Postgres supports returning syntax on updates.
As far as I know check constraints are still _silently_ ignored in mysql 5.8. silently! That illustrates exactly why I don't trust mysql and probably never will.
What is one advantage that mysql has that outweighs its enormous pile of garbage it brings along? What is one advantage worth not trusting your tool to work?
> What is one advantage that mysql has that outweighs
Replication & performance for most workloads. I've found it helpful to think of MySQL as less of a relational database, and more of a KV database with secondary index support and a SQL api.
I'm still not sold that any slight advantage in either of these cases is worth not having a flexible and trustworthy tool.
> I've found it helpful to think of MySQL as less of a relational database, and more of a KV database with secondary index support and a SQL api.
And that's not what most businesses need, especially right out of the gate.
From my understanding that's what those large companies you mentioned and Uber do. They also have people who contribute code to mysql or mariadb, allowing them to fix any issues they have. Most businesses do not have that luxury nor would they be best off with only a kv store.
Everything you've pointed out are great examples of technical demerits... but none that really transfer over in any negative way to the business besides developer frustration. I wouldn't be surprised if MySQL got replication out so earl because it was such a POS that needed a better backup strategy, but that doesn't change the battle-hardened RDBMS it's become today.
> And that's not what most businesses need
Most businesses don't know what they need until they're a few years in, and database software isn't going to be on any execs top 100 list of things troubling the company.
> They also have people who contribute code to mysql or mariadb
Contributions that are from non-trivial deployments, supplemented with countless years running in production across millions of installs of Wordpress and phpBB thanks to cheap web hosting - I don't think there's any other database in this category that can claim it has seen more service.
It's just another software tool like any other, sorta pointless to shit on it just because you don't have a problem where it works.
I honestly don't know why anything but institutional inertia is even a sane reason to use MySQL. There are better rdbms. There are better key value stores.
Because you clearly lack experience to make this kind of call, but that doesn't stop you from throwing around technical rhetoric like you know what you're talking about. You're essentially claiming that everyone that has or will choose MySQL is an idiot/doesn't know better, and that clearly you know more about the context of our problem, business, and challenges than we do.
Why is that surprising? When I worked in a business to business compsec role, for instance, the vast majority of our customers didn't know how to use `ssh` properly or what public and private keys are. Just because someone has the title "dba" let alone "developer" doesn't mean they know the first thing about the relational model.
> Most businesses don't know what they need until they're a few years in, and database software isn't going to be on any execs top 100 list of things troubling the company.
A database is a developer tool, it should be evaluated on its technical merits. If its frustrating for developers, it means its harder and more expensive for the business to get what it wants.
And MySQL is such a developer tool, which has been selected by many developers for many reasons for many classes of projects.
Until 5.7 I believe mysql required extensions to do multi master as well.
9.6 is supported and the next release (scheduled soon) will support 10. Those changes will eventually end up in 12.
https://www.2ndquadrant.com/en/resources/bdr/ https://blog.2ndquadrant.com/news-and-roadmap-for-bdr-multi-...
I'm not sure what you mean by somewhat equivalent. Both are primarily asynchronous multimaster approaches.
This suggests to me it's not really open to the public. And there is no release 2.0 on github (https://github.com/2ndQuadrant/bdr/releases).
Feel free to correct me if I'm wrong and the 2.0 release is accessible without a 2ndquadrant support contract (or reverse engineering the changes from the github repo branch, which pretty much ensures you're never going to production with it), I'm genuinely interested.