Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing.

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.



sort by: page size:

> I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing

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:


> one is clearly better

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.


> why, in a world where PostgreSQL exists, would anyone use MySQL.

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.


> As much as I vastly prefer PostgreSQL, I will tell you that MySQL is much more preferred in enterprise settings, probably 8 to 1 in the environments I've seen.

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.)


>>Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres.

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.


> I'm an infrastructure dev, not an DBA or an advanced SQL user, I never used window functions, or wrote a query that filled half the screen, or have a thick web of foreign keys ... If you keep things damn simple so you have confidence in efficiency and performance, then MySQL works pretty damn well in my experience, and Postgres, for all its academic correctness and advanced query feature set, has been pretty damn annoying.

At that point you're effectively using MySQL as a key/value store with an SQL interface, rather than a full RDBMS.

Which is, in fact, pretty much exactly what MySQL was originally designed to be and it's extremely good at it.

> If you keep things damn simple so you have confidence in efficiency and performance

I can have that level of confidence on a minimally tuned (albeit sensibly indexed, you still have to make sure the indices you need -exist- on anything, realistically) postgres at levels of schema/query complexity where getting mysql to handle it -at all- would be ... an experience.

Having used both extensively, I'd say that there's a lot of knowledge when using mysql that's basically "introducing complexity into your application and query pattern to work around the optimiser being terrible at doing the sensible thing" and then there's lots of knowledge when administrating postgresql that's "having to pick and choose lots of details about your topology and configuration because you get a giant bag of parts rather than something that's built to handle the common cases out of the box".

So ... on the one hand, I'm sufficiently spoiled by being able to use multi column keys, complex joins, subqueries, group by etc. and rarely have to even think about it because the query will perform just fine that I vastly prefer postgres by default as an apps developer these days.

On the other hand, I do very much remember the learning curve in terms of getting a deployment I was happy with and if I hadn't had a project that flat out required those things to be performant I might never have gotten around to trying it.

So, in summary: They've chosen very different trade-offs, and which set of downsides is more annoying is very dependent on the situation at and.


> but do people know why MySQL is lagging behind so much

Because for 99% of the MySQL user base there isn't a need for these features.

Those using MySQL at scale are using them as dumb key-value stores with horizontally sharding. Those who aren't typically are using them with an ORM and so they aren't dealing with the database at the SQL layer.

Everyone else who is manually writing SQL generally was on or moved to Oracle, Teradata, SQL Server, PostgreSQL etc anyway.


>I find it quite patronizing that you assume the only reason anyone would use MySQL is that it is the default choice.

Really? Defaults are supposed to be sane and the best-fit-for-most-common-scenarios... so it's a little patronizing to automatically assume your project is just so special that defaults are not good enough.

Defaults should be good enough until they have been proven to not be good enough. Don't over-engineer your project.


> As early as 2001-2002... from mysql to postgres.

MySql was pretty bad in the first versions. I'm in the enterprise/erp development world, and when I look at mysql when it start to show in the radar, I can't believe the joke.

MySql get good around 5? Now I can say all major DBs are good enough not matter what you chosee, (still think PG is the best around) but MySql was always the more risky proposition, the PHP of the db engines...


> why do these companies choose MySQL over Postgresql?

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 always got the impression (since I started using it in Prod in the late 90s) that the MySQL team had never worked on an RDBMS before, even as users, and didn't really understand it.

IIRC that's actually correct.


> Why would anyone start a new project with MySQL? Is it really superior in anything?

It's the most developer-friendly thing out there. Particularly for a datastore CLI, which is inherently something you use rarely, MySQL's is just a lot nicer, more discoverable.

I think it has the least bad HA story among (free) traditional SQL-RDBMSes too (not that I understand why anyone would start a new project on a traditional SQL-RDBMS at all).


> Someone really needs to explain to me why PostgreSQL users in particular seem to always want to bash the competition in order to justify their technology choice. It's been going on for years against MySQL/Oracle first, then MongoDB/NoSQL and now SQL Server. It's odd.

I think it's less about PostgreSQL, and more about the particular products:

1. Oracle has always been a piece of crap from a technology standpoint. There are good reasons businesses use it, but they don't have to do with a robust, core product.

2. Early versions of MySQL were a joke. It's pretty good now, but for a long time, it was the butt of many jokes for good reason. It was very easy-to-use, and fast if you didn't need data consistency, but it didn't quite work right.

3. Stonebraker aside, I haven't heard much bashing of NoSQL. It's used in many places where it's the wrong tool for the job (JOINs are useful), but it's great where it is the right fit. It's just that MongoDB, in particular, isn't great if you have data integrity or performance requirements you care about.

4. I don't even know where to start on SQL Server. Seriously. The only reason to use that dog is if you're tied to a Microsoft-only shop.

There are lots of great technologies out there -- Cassendra, Google's Bigtable, memcached, modern versions MySQL, etc. -- which I've never heard people mocking. Conversely, users of most of those tend to make fun of the broken databases just as much as PostgreSQL users do. It's just that you see the PostgreSQL users doing more mocking simply because there are more of them out there.

Footnote: I'm developing on a MySQL+MongoDB stack right now. MySQL is great, but MongoDB is a bad joke.


> MySQL is a pretty poor database, and you should strongly consider using Postgres instead.

It's not like it's an industry secret either: when I started my CS training in 2007, the first course was about relational databases and one of the first things the teacher told us was that MySQL was pretty sucky.


> Plus MySQL kind of rocks.

Agreed. I prefer Postgres for personal projects, but MySQL is a fine database. Honestly, even a relational DB I wouldn't want to use again (DB2...) is still pretty solid to me. The relational model is pretty damn neat and SQL is a pretty solid query language.

I wonder how many people disagree with that last part in particular...


> Coming to MySQL was like stepping into a parallel universe, where there were lots of people genuinely believing that MySQL was a state-of-the-art product.

> (it seems most MySQL users and developers don't really use other databases)

> But perhaps consider taking a look at the other side of that fence at some point, past the “OMG vacuum” memes.

> Monty and his merry men left because they were unhappy about the new governance, not because they suddenly woke up one day and realized what a royal mess they had created in the code.

> I am genuinely proud of the work I have been doing, and MySQL 8.0 (with its ever-increasing minor version number) is a much better product than 5.7 was

————————-

There’s definitely a lot of “our users are sheep” and “everyone else is dumb” going on in this post.

Heck, it may even be true. But you can’t really argue that hybrid author isn’t saying it.


>>The strangest thing to me is not that MySQL is more popular than Postgres, but that anyone uses Microsoft or Oracle at all. Not only do they cost a lot, but from a purely technical standpoint they are worse.

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.


> what's wrong with MySQL?

After many years of security issues and its general inability to be a good database, I refuse to install it on any of my own boxes. If I need something heavyweight, I'll use Postgres; otherwise it'll be SQLite - both of which manage to be more secure and competent than MySQL.


> The sad part is that databases have evolved and became much better in the last 20 years (I started with MySQL 3.x), but we just don't use them.

Yes, it's a bit like buying a set of silverware and insisting on using the handle as the business end incase you decide to switch your tool.

next

Legal | privacy