"The short answer is performance. To effectively implement things we've got on our roadmap, we need things that (current) MySQL doesn't support: array types are critical for efficiently supporting things like parameter values, recursive query support is critical for fast graph traversal operations, things like INTERSECT are handy for query generation, and we rely on fast joins (MySQL's nested loop joins don't always cut it). It's much easier for us to support databases with these features than those that don't. For fairly divergent database targets, it becomes really hard to get the performance we want while simultaneously keeping our codebase manageable...

We certainly didn't make this decision cavalierly; it was made after around a month of benchmarking various solutions ranging from traditional databases like PostgreSQL to document stores like MongoDB to KV stores such as Riak to graph databases like Neo4J. For Puppet's particular type of workload, with Puppet's volume of data, with Puppet's required durability and safety requirements...I maintain this was the best choice. "

http://groups.google.com/group/puppet-users/browse_thread/th...

This could be a symptom of which businesses choose which databases. Large established businesses are probably going to prefer the commercially supported database, and are probably also going to have the resources to build impressive systems.

Built-in two-way (aka master/master) replication.

For what it's worth, I've used Postgres in production systems with great success.

MySQL has supported this since at least version 3.2.3, released in January 2001.

MySQL supports

• Single master to one slave • Single master to multiple slaves • Single master to one slave to one or more slaves • Circular replication (A to B to C and back to A) • Master to master

Postgres supports

• Single master to one slave • Single master to multiple slaves

(lists from http://www.theserverside.com/feature/Comparing-MySQL-and-Pos...)

From the comments here though I'm not missing anything.

> Schema-less data, array columns, queueing, full-text searching, geo-spatial indexing, it's insane what Postgres can do.

Ok for arrays and geo. Maybe for integrated search. But where is the line between bloat and useful features? Do they really need queueing in the database itself, or schema-less parts? Each part is something that needs maintenance, possible bugfixes and caring about when you update any internal part. Just checking for regressions and keeping them up to date with internal interface changes is going to take some time.

See a similar issue which came up in the mysql -> drizzle move. How can we judge what is slowing the project down and what is going to make it into production somewhere?

While it may seem nice and convenient to have all these different features in one nice package, I'm struggling to see what that's such a good idea in the long run.

The thing with the separation of concerns means you use software that does one thing and does it well. Maybe this comes with a greater maintenance cost, I don't know, but I think I'd feel safer with that, because of the maintenance reasons you list.

All RDBMS engines have a variety of features that are not necessary in all deployments.

MySQL is fine. Even if you accepted the premise that Postgres had become the better piece of software, MySQL has a massive installed user base and every opportunity to catch up and improve.

A great example of this is MariahDB just provided a module to handle geospatial data in the database as well.

If it has any significant deficit, MySQL is not going to "catch up." I'm not necessarily agreeing with the article, but don't fool yourself.

If things actually worked that way, Windows 7 would have been worse than Vista, and the quality of iTunes today would ensure Apple could not compete for the future of the music market.

The other problem is that every host offers MySQL. Not so with Postgres.

You could just as well say that multi-text-encoding sort/group collation, compound keys, or, for that matter, indexes on anything other than primary keys, are "application-specific function[s] that shouldn't be bloating a database engine"--and then go back to using BerkeleyDB.

The point of relational databases is not data warehousing, nor is it to batch-execute preprogrammed queries on extremely-denormalized data at hyperspeed (that's what NoSQL and all that other noise is about.) The niche RDBMSes fill, is that they provide an abstraction layer for doing unforeseen data analysis using arbitrary relational projections and selections while the database remains online, without having to worry about (or modify!) the underlying data-structures. "SELECT user_id WHERE ST_Distance(location, my_house) < 100 AND has_beer = TRUE" is a perfectly sensible question to ask of any database that stores locations of things (and whether they have beer), whether or not that's part of the application that put the data there.

Should there be special functions for querying the characteristics of JPEGs stored as BLOBs? How about PNGs?

Where does this end? Just because a couple of float values happen to represent latitude and longitude doesn't mean the DB engine should integrate geospatial logic.

With Erlang QLCs :)

GIS most certainly belongs in the database. You don't want to load gigabytes of geo data as points in memory and build and filter geometries in whatever your application is, anymore than you want to load any non-trivial dataset in-memory and do your filtering in your application language.