Why I Choose PostgreSQL Over MySQL/MariaDB

Nerval's Lobster writes For the past ten years, developers and tech pros have made a game of comparing MySQL and PostgreSQL, with the latter seen by many as technically superior. Those who support PostgreSQL argue that its standards support and ACID compliance outweighs MySQL's speed. But MySQL remains popular thanks to its inclusion in every Linux Web hosting package, meaning that a mind-boggling number of Web developers have used it. In a new article, developer David Bolton compares MySQL/MariaDB 5.7.6 (released March 9, 2015) with PostgreSQL 9.4.1 and thinks the latter remains superior on several fronts, including subqueries, JSON support, and better licensing and data integrity: "I think MySQL has done a great job of improving itself to keep relevant, but I have to confess to favoring PostgreSQL."

Comments

I choose MS SQL Server

[Anonymous Coward]

Best of all worlds. And guess what, in the grand scheme of things, the price is a drop in the bucket compared to salaries.

Re:I choose MS SQL Server

[Anonymous Coward]

MS SQL server has its place:

1: Oftentimes a company already has it licensed, so might as well use it.

2: It is auditor friendly, with the pieces of paper (FIPS, etc.) that don't mean much in real life, but do mean a lot when ISO, or other audits happen, and you have to justify your existence and design decisions. (For those who say certificates/certifications don't matter, one place I worked actually had auditors that would fire people on the spot for "failing to have authority to run the equipment" if their RHCE/MCSE/CCIE certs lapsed.)

3: Finding MS SQL expertise is easy.

4: MS SQL does work and is decently secure. For 99.99% of tasks, it is just as good as Oracle.

This isn't to say that PostgreSQL is bad... but there are times where MS SQL is the ideal choice.

Re:I choose MS SQL Server

[Anonymous Coward]

In terms of licensing, I think the MS sales force is learning too much from Oracle. We are backing out from supporting MS-SQL due to the insanely expensive licensing terms for deployments that MS sales is starting to apply to it.

Re:I choose MS SQL Server

[Richard_at_work]

The Express Edition of MS SQL Server is pretty damn good for 99% of the deployments you would consider MySQL for, and its free. The limits are memory usage (1GB per instance), database size (10GB), CPU (1 physical or 4 cores) and instances (50 per server).

That should run most websites and business apps fine. Because most websites and business apps are drastically overspecced and under used.

Re:I choose MS SQL Server

[DarkOx]

Was the last version of SQL Server you used 7.0 or something. I love to dump on Microsoft as much as the next guy, but honestly SQL Sever 2000 on is pretty damn good. As far as falling over when hit with significant load, I was running a 60TB database on the first Itanium versions of SQL 2000 back in '04 and it never 'fell over'.

The project was big enough and cost enough Microsoft was willing to send people out to help us tweak and tune. That is all we did though nothing exotic like a custom build or anything. Just end user tuneables and guidance on schema around partition views and like.

So really there are plenty of legitimate criticisms of the Microsoft platform family but SQL Server falling over ain't one of them.

Re:I choose MS SQL Server

[Gr8Apes]

I've had the misfortunate to work with 2000, 2005, 2008 and 2008 R2, and 2012, and every single one of them has failed spectacularly, many of them with the same basic issue, that wonderful escalating locks problem, which MS spins as a "performance improvement" much like driving a bus off a cliff improves its performance, and in much the same way.

Re:I choose MS SQL Server

[phantomfive]

I don't know, in my experience, I rank it like this:

1) Postgresql - full of random features that makes things easier and better (you can use almost any language for stored procedures, for example. Not huge, but nice).
2) MS SQL - Works fine, not too interesting.
3) MySQL - full of random feature that makes things harder (do you know you can't rollback a transaction that modifies a table? Every other database can....).
4) Oracle - Has all the features, but some of them have very funky syntax.

-- -- -- -- -- --

If you support using the 'best tool for the job,' then the choice is obvious, following this algorithm:
1) If you're using a Microsoft stack, use MsSQL (I've tried using entity framework with MySQL....it mostly works, but it's a pain).
2) If you're using a stack that integrates well with MySQL, use MySQL.
3) If you are in desperate need of corporate CYA, use Oracle.
4) For anything else, use Postgresql. You won't regret it.

Re:I choose MS SQL Server

[phantomfive]

No, you misunderstood what I wrote. I was referring to the fact that MySQL DDL is not transactional. So if you run an 'alter table' command, don't expect to be able to roll it back. Seriously though, even SQLite offers this feature, so MySQL is just a dunce.

The main difference that I see is that Postgres fans generally have the same zeal and lack of experience that Rails fanboys exhibit. I am not sure where you fall but you are doing a disservice to our community by spouting false claims when you do not understand what you are talking about. (That sounds like a rails fanboy to me.)

I'm pretty sure it means you're a moron. Or rather, you should have thought a little before spouting insults.

Duh

[Anonymous Coward]

Who trusts MySQL with important data? No one who knows about PG. Good web frameworks like Django prefer PG, while crap ones like Drupal and other PHPtards prefer MySQL.

A more intringuing question...

[leonbloy]

would be why I still choose to read Slashdot instead of ... anything else.

Let me quote, from the comments thread at a recent article by same submitter:

Could we stop having Dice articles submitted by Nerval's Lobster? Why not fully disclose that the story was submitted by the corporate parent of Slashdot?

Another user, in the same thread, had speculated:

What comes next, a thread on "is Emacs better than Vi"?

No, sir, you were utterly wrong. It came "Postgresql is better than Mysql".

SQLite3

[fyngyrz]

And for many tasks, you don't need any of that. Have a look at SQLite3 (also, it's built into Python, which can be handy.)

Worried about stability? You can compile the SQLite3 source code right into your project. That way, your databases always match your shipping product, indefinitely, period.

It's not usable for everything -- only a decent subset of SQL is supported -- but you might be surprised at just how much is there, and working well.

Re:SQLite3

[Bacon Bits]

SQLite3 is a fantastic product, but it's primarily intended as an embedded SQL database, not an RDBMS. They're not really intended to do the same things.

On the other hand, at least SQLite doesn't "feature" silent non-deterministic aggregates.

Postgres hands down

[infernalC]

I come from a Sybase SQL Anywhere shop. It never ceases to amaze me how stuff that can be elegantly expressed in a couple of queries in Watcom-SQL typically takes four times as much code in MySQL's dialect. I love Sybase's support for the ANSI standards, subqueries, Java/.NET/C/PHP/Perl stored procedures when they are the right tool for the job (ever needed to resize raster images in an INSERT trigger coming from some third-party application?), and great drivers. I shouldn't have to spend 10 minutes trying to figure out why MySQL doesn't support the standard casting string concatenation operator by default (||), or why subqueries don't work like they ought, etc.

Having used Postgres, all of the worthwhile MySQL features are there, most of the SQLA features are there, and the pain level is much, much lower in Postgres than MySQL for someone coming from a full-featured commercial RDBMS.

What really sucks is all of the applications that are so coded around MySQLisms that they don't run on ANSI-compliant engines.

Re:I thought we were over the whole SQL thing

[ArcadeMan]

Nope, we all moved to XML.

In my experience

[Trailer Trash]

And I'm probably going to step on a lot of toes here, but people like me strongly prefer Postgres to MySQL. And by "people like me" I mean folks for whom their first real rdbms experience was theoretical or "commercial". I did both.

I used ingres in college to a small extent and then the Ingres commercial product for years after that. I have also used Sybase and Oracle professionally. PostgreSQL easily walks among the giants of that industry.

Every time this discussion comes up the MySQL side has to say "yeah, but..." about a thousand times. MySQL doesn't do ______ properly? "Yeah, but if you just install this other piece of software and change a couple of config files it *can* do it.' Well, con-fucking-gratulations!

The point is that PostgreSQL does exactly what it should do out of the box. I don't have to change a configuration file to make it ACID compliant, fast, correct, whatever. It just works and works correctly out of the box.

Every time someone tells me how easy MySQL is to set up they've betrayed their experience level in this realm.

I know a lot of you are going to mod me down - I don't care. But why not reply instead?

Re:I thought we were over the whole SQL thing

[Anonymous Coward]

I moved all my XML into JSON, then stored it in a MySQL table named "JSONXML" with a single column named "data". I call it "web 3.0 agile database". I'm in the process of writing a manifesto and bunch of books about it.

Re:Postgres has referential integrity

[rycamor]

That's not even close to what "referential integrity" means. In fact, it could be used to accomplish quite the opposite.

OIDs are one feature of PostgreSQL that should be buried inside the implementation and not allowed to be accessed from the developer side. Otherwise you are pretty much completely going around the whole point of the Relational Model. If you are developing an application in such a way that it needs pointers to rows, you might as well just store data on the filesystem and be done with it. Or use one of those fancy NoSQL thingies and enjoy your data corruption.