

It's the Postgres Age - craigkerstiens
http://dickey.xxx/mysql-is-done-it-s-the-postgres-age

======
kitsune_
Horrible article. The same guys that pimped NoSQL three years ago now just
hype something else. I have nothing against Postgres (I use it myself) but
inflammatory articles like this are of use to no one other than their authors.

~~~
TazeTSchnitzel
He's half right, it is the end of the MySQL age. Well, specifically, the LAMP
age. MySQL is still used by some people. But that doesn't mean we're in the
Postgres age.

------
sciurus
Puppet Labs just released PuppetDB an optional (for-now) component of their
configuration management software. The supported backends are HSQLDB and
Postgres. When asked why MySQL wasn't supported, the developers' response was

"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...](http://groups.google.com/group/puppet-
users/browse_thread/thread/66b123570d54a47f)

------
lmm
Worse is better. MySQL's terribleness is its feature; it means you stop and
think before putting business logic in the database, writing a stored
procedure, or joining on five tables. While it's a worse database, the
/systems/ I've seen built on MySQL are all better than those built on "real"
databases.

~~~
sliverstorm
_While it's a worse database, the /systems/ I've seen built on MySQL are all
better than those built on "real" databases._

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.

~~~
lmm
No, the trend (and I'm generalizing from a small number of examples) is in the
opposite direction; it's the small businesses or startups that use MySQL and
produce better systems. Slightly bigger companies use Postgres and produce
worse systems. Actually big companies use Oracle and produce terrible systems.

------
sciurus
"I seriously want someone to tell me just ONE feature that MySQL has over
Postgres. I ask everybody this question, and I haven't heard a single thing. "

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

~~~
dickeytk
Postgres has had solid replication since 8.4

~~~
sciurus
It was only in Postgres 9.0, released in Septermber 2010, that support for a
"hot standby" (e.g. master/slave replication where you can run read-only
queries on the slave) was added.

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...](http://www.theserverside.com/feature/Comparing-MySQL-and-
Postgres-90-Replication))

------
binarycrusader
Wonderful, this is also posted on an '.xxx' domain so it is categorised as
adult material by my company's proxy. Gee thanks.

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

~~~
mrgreenfur
With dickey no less!

------
kloncks
Aside from the lovely Link Bait article, imagine my surprise at seeing a
'.xxx' domain on HN's front-page.

------
sp332
Hm, the first .xxx domain I've seen on HN and it's not even off-topic
(although a little flamebaity).

------
dkhenry
I wonder how posts like this make it to the front page. This is clearly a
opinionated and poorly researched article that gives no evidence for any of
its claims, except that a few features this user wants are included in
PostgreSQL. There is still plenty of space PostgreSQL has to make up before it
is better then MySQL in every way. The knowledge gap alone is enough to keep
MySQL around.

~~~
dickeytk
where does postgres need to catch up? and what knowledge gap?

~~~
dkhenry
The knowledge gap is how much industry knowledge there is about how MySQL
preforms in large scale applications, and the amount of people who can help
you tune it. Because MySQL has such a large deployment base there is a whole
industry around performance tuning and its easyt to find an engineer who has
experience using it. Even if they were technically equal which they aren't
that one aspect alone would tip the scales to MySQL

------
viraptor
I was actually discussing this today:

> 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?

~~~
FuzzyDunlop
And where will it stop? Will it have a built in email client next?

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.

~~~
bsg75
Many Postgres features and packages can be enabled / disabled via configure,
and the engine built, if you want a "leaner" deploy.

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

------
danvideo
MySQL support is fantastic - they offer optimization along with
troubleshooting - and respond immediately. Also, they are relatively cheap as
far as support goes.

------
tudorw
I know MySQL.

------
norviller
I have nothing against Postgres, I use it daily in many, many projects, but
this article is ridiculous. How did this make the front page?

------
Jarred
It's interesting that people are upvoting this submission, yet the comments
are almost all calling it flamebait.

------
will_work4tears
Wait, one box? What are clusters then?

------
jcfrei
did this post just disappear from hn? I cant find it on the front page anymore
and neither on the second, third, or new... something to do with the xxx tld?

------
adventureful
Nothing like exaggeration in headlines taken to the extreme.

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.

~~~
falcolas
Agreed. And now that Oracle and MariahDB are competing, we're actually seeing
a lot of progress on getting new versions and features out the door.

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

~~~
DavidAbrams
MariaDB

------
DavidAbrams
The article's arguments aren't that convincing. Geospatial indexing? That's an
application-specific function that shouldn't be bloating a database engine. If
anything, the grocery list of crap mentioned by this article makes me DOUBT
Postgres's focus on being an efficient database.

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

~~~
masklinn
> That's an application-specific function that shouldn't be bloating a
> database engine.

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.

~~~
blutonium
Yeah, that's why they're supported in PostgreSQL, MySQL, Oracle, DB2, MSSQL,
even SQLite... Multi-dimensional data isn't restricted to the world of GIS,
and B-Trees are not up to the task.

