A lot of decisions are made holistically instead of a "purely technical standpoint". In large companies where there are still IT departments (e.g. use of Active Directory), MS is still very much the de facto platform, and SQL Server is the "logical" choice.

There's been a perception for a long time that MySQL was "more lightweight" than traditional RDBMS's and therefore "faster", the same thinking that perpetuates NoSQL solutions today.

Originally Postgres didn't even support SQL. mSQL was developed as an SQL interface to Postgres in the mid 90s. When it turned out Postgres was dog slow on the old-ass hardware the devs were using they just implemented their own lightweight db and mSQL became the top pick for new OSS-based systems. But mSQL was commercially licensed, so MySQL was created for personal use. Since it reused the same API as mSQL, everyone just adopted MySQL as a 'drop-in' replacement. So MySQL is lightweight and fast and free and Postgres is a dog slow incumbent.

I guess you could compare it to how many people feel Java is a humongous pig that can't scale and PHP is fast and lightweight. And obviously lots of sites use PHP. But some shops choose Java because they want something PHP can't offer. (Note: this is not a fair comparison to MySQL and Postgres in any way, but it shows the weird 'feelings' people get for different software)

But also: MySQL has more DBAs, a higher number of installations, more 3rd party support, bigger user/dev community, and in general is more popular.

> technically, is MySQL less capable than Postgres?

Each has individual technical benefits and drawbacks the other doesn't have.

> Would it be wrong to start a new business on MySQL?

What, like, ethically?

MySQL is just a tool. I could 'bash' a table knife by saying it's a dull, heavy piece of shit compared to some other knife, but guess what? Everyone uses table knives. They don't typically use them to debone fish, however. Look at your use case and pick the tool you feel comfortable with that fits it best.

I seriously trialled and compared Postgres vs MySQL at the start of a major major project, and MySQL had a few clear wins for us (mainly replication) while the features Postgres had weren't in our current roadmap's requirements (the biggest regret that caused me was not having stored procedures). That was in 1998/1999. I now seem to be stuck on a career path where everything is MySQL and switching to Postgres anywhere seems to have huge back pressure from everyone I work with - even though at least half of them know damned well (like I do) that MySQL hasn't been the right choice for a couple of decades almost.

:shrug:

They shouldn't fear a competitor that does everything they do. They should fear a bunch competitors each doing a set of features a given customer needs.

SQL Server is Microsoft's best software product, but why would I even bother with it since both MySQL and PostgreSQL do everything I need from an RDBMS, for a tiny fraction of the TCO and with comparable if not better performance and much better platform support? And why would I even consider it when non-relational datastores are a much better fit for most of my data? It makes sense if you are into Windows, but makes no sense whatsoever if you are not.

Agreed. SQL Server Management Studio is fantastic and is one of the main reasons I enjoy working with MSSQL.

Unfortunately Postgres severely lacks in the tooling department. PgAdmin 3 used to be good, but PgAdmin 4 is simply horrendous. It makes me dread interacting with Postgres.

You are refuting a claim I never made. My issue is not with the limitations, these are a fact of life with any and all technology.

My issue is with silent data corruption and subtle issues that break expectations

Thus, requiring any user of the system to be fully versed in all the documentation and to be prescient enough at all times when interacting with the database.

I can’t make such guarantees, and PostgreSQL follows the principle of least surprise much better. If I have two options and one of them has odd silent failure modes and the other holds your feet to the fire to ensure correctness. I will consistently choose the latter.

You could also ask why would anyone use Postgres? Either question is equally absurd. If MySQL and its forks work well enough for Google, Facebook, Uber, AirBNB, Alibaba and Linkedin, why should anyone take it on face value that Postgres is an unambiguously better choice?

That said I've toyed with switching in the past. Ten years ago, the MySQL query optimiser was fairly junk and I wanted to switch for that alone.[1] The main thing that held me back was that my application has hundreds—quite probably thousands—of SQL queries coded into it.

Despite "SQL" being a notional standard, even the most basic queries would need to be extensively reformatted to be compatible with Postgres. The effort required to rewrite all of these queries simply can't be justified, particularly because we simply don't have any problems with MariaDB. The query optimiser is a lot better now, such that I now rarely encounter situations where a sensible query doesn't yield an efficient execution plan.

[1] Between 2000 and 2007 I had spent a lot of time with MSSQL for a different project and I had grown to appreciate its excellent query optimiser and execution plan visualiser. Ten years on and I still haven't seen any F/OSS solution that does as good a job as SQL Server 2000 in this regard. The most recent version I've used is 2005 so it might be even better today. And believe me, I was not a fan of Microsoft in the 2000s.

There is not. Counterpoint: Wikipedia. It's definitely not like this where SQL is used by 99.99999% of everyone and nobody has even heard of QUEL.

> It is not like Postgres was a new project and they simply had to pick something. It had been with us for a decade before deciding to take the SQL direction.

It wasn't even remotely popular until they made that change. In fact, it wasn't even remotely popular until years after they made that change.

Probably the interesting point is that they could make this change and not really lose any necessary functionality. Clearly the query language was not particularly important.

> Thing is, I'm not sure SQL is even all that popular nowadays.

A suggestion so laughable I have no response. SQL has never been as popular as it is right now in history. Even with the introduction of noSQL databases, SQL continues to gain. All boats are floating.

> By your logic, databases should be adopting what best aligns with that programming model rather than clinging to SQL.

Is there something they can adopt? If you presented me with 2 options, lets call one X and other SQL then we could have discussion about adopting one or the other. If this X was indeed more popular then maybe they shouldn't cling to SQL. But the dozens of ORMs across dozens of platforms is not an alternative that can be chosen.

> It seems the SQL crowd still can't get over that there might be an alternative.

If you've been around long enough you wait until someone can bring the receipts.

> The most common SQL bug I see in my travels can be distilled down to something like:

Yeah that is pretty common. Would it be nice if that wasn't an issue? Sure. I'm not arguing that an alternative might not be better, it's just not better enough. These are pretty minor annoyances. If you just made a language that fixes this one issue and left everything else alone, it would be better than SQL, but you wouldn't get anyone to switch. You'd be better off proposing this as a feature addition to SQL and maybe in 20 years you'll be able to use it.

It's not a terrible DB to work with. I'd go with something like Postgres > Oracle > MSSQL > MYSQL.

And, mind you, if you care about ease of use/maintenance rather than performance, I'd swap Oracle and MSSQL on that list in a heartbeat.

But also need to say... Every year when the Oracle folks came by, all of the managers would get super antsy/nervous. They would always find 'something' that we had done wrong to warrant an additional payment on our contract. Their shenanigans were so bad that we weren't allowed to install ANYTHING downloaded from Oracle without checking with someone first.

Every database engine makes different trade-offs, or does some things better than others.

I've found that SQL Server handles complex queries over large data sets fantastically well, easily outperforming Oracle or open-source DBMS systems in like-for-like scenarios. It often papers over missing indexes shockingly well, because it automatically uses temporary hash indexes that it can build in parallel. Up to about ten million rows this can be fast enough that developers don't even notice that they forgot an index!

However, it has very high minimum latency that cannot be fixed through any mechanism. Not via RDMA, shared memory, named pipes, local loopback, or any other means. It always takes SQL Server about 125-150 microseconds to respond to a query, not matter how trivial, such as "SELECT 1". This makes it terrible as a KV store, and makes some types of ORM very sluggish when chasing references in code.

Similarly, there have been several articles published saying that while Postgres is well-roudned and featurefull, it has high write-amplification that makes it an absolute no-go past a certain scale. Many orgs have written long blogs about how they started with PG and were forced to migrate to MySQL to get to the required scale.

I feel that the DBMS space is still immature, and there are very fundamental things missing. E.g.: There are no enterprise-ready open source pure in-memory relational database engines that have capabilities comparable to SAP HANA. I'm also yet to see a DBMS with decent programmability, so that developers don't need to write App->ORM->DB layers over and over.

Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do).

I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch.

I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.

Oh for sure. It took me forever to figure out how to get Oracle running in a docker image as a new Oracle user. I'm not sure if I ever even figured out how to create a table. Postgres was hard to learn initially coming from the simplicity of MySQL and Oracle feels another step harder.

I didn't say I expect commercial software to perform better though, just that I expect them to be competitive.

I also wouldn't choose a commercial db personally but dunking on them doesn't make sense either. The engineers behind them are just as good as those behind OSS.

Yeah, I am one of those people. Needed a database in 2005, and MySQL was the de facto choice. Got used to it and never ran into problems that couldn’t be solved by getting better at schema design and indexing.

I never felt limited by MySQL and I am very comfortable with it, so never felt the need to try anything else. I might be missing something, but there is an opportunity cost in switching without a real motivating reason.

No, it was not. FoundationDB's SQL layer was a joke. The system was horribly slow. Every DBA that I talked to that tried it said that it did not deserve the hype that it got.

That's largely because enterprises often have big investments in SQL server, OracleDB, and/or DB2, and are only using open source engines for more lightweight purposes, and/or as part of cloud transitions where they are just taking vendor default options or whatever options was supported when they came on or longest.

At least, that's my experience working in enterprise and being literally the single voice urging even considering pros and cons before using MySQL-by-default with no particular rationale in a transition effort (which resulted in us using Postgres.)

Show me mssql vs PG speed comparison on a recent industry standard benchmark.

> and costs you a fortune right?

Are you witless enough to think I'm unaware of the wallet-raping, labyrinthine licensing of MSSQL?

> Hope the job security is worth...

Since you apparently can't understand, let me spell it out for you: I've recently installed PG to start learning it because, depending on the problem, it IS the best solution. I do hope you can stop feeling the need to protect your pet software package and undersand these are in the end just tools to solve problems.

An ass to drag onto the carpet. In enterprise speak, "support" means "legal liability". You have to be able to sue someone if it fails and loses your company money. This was taught to me by an old IT hand back when I was a young naïve Linux kiddie "you have to be able todrag somebody's ass onto the carpet when the shit breaks".

Oh yes, and there's also brand recognition and a large pool of certified Oracle or SQL Server DBAs to draw from when making hiring decisions. Yes, technical people will know that Postgres is solid and will know how to spot good people to maintain a Postgres installation -- but the person signing off on the IT budget is a total normie. He will smile when he sees familiar names and make a lolwut face when he sees postgres.

Relatedly, Postgres doesn't have a yacht. Oracle's yacht won the America's Cup.

For some definitions of better.

I started with MySQL. At some point I encountered project based on Postgres. It just came with its own set of quirks you had to deal with. It didn't feel like, wow, this is so much better. It was more like, yup, it's a database, it just COUNTs slowly and needs to be VACUUMed. I had more issues and questions at the time how to do things I knew how to do in MySQL, I figured them out, but those two are the impression that were left.

Then I encountered MsSql Server and it was pleasent enough. For my next project I'd probably choose Postgres but not because it created any kind of sympathy in me. The only thing I reallty liked was EXPLAIN.

MySQL has one advantage in my opinion. At least it had two decades ago. It was simple. It did things that realtionational databases are good at, in fast and easy manner. It didn't have constructs like nested queries, recursive queries, triggers or stored procedures with cursors which databases like Postgres had, because who's gonna stop them, but their performance is horrible and must be horrible because they step out of the realm of fast relational model into the realm of normal programming which algorithmically is way slower (and that's the main reason we use databases at all).

So MySQL in my opinion teaches you about what the databases are good at. It helped me immensly when dealing with slow queries later in life in Postgres, SQL Server and even Oracle.

While "people" complaining is basically meaningless, I don't know why they'd be doing that about SQLite. It's used in most phones, all copies of Windows 10+, and countless other places.