It's the Postgres Age(dickey.xxx)
dickey.xxx
It's the Postgres Age
http://dickey.xxx/mysql-is-done-it-s-the-postgres-age
47 comments
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.
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.
agreed
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...
"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...
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.
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.
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.
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.
"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.
Built-in two-way (aka master/master) replication.
Amazon RDS support.
RDS is awful. The interface is shitty and buggy, offers graphs that you can't do anything with, the backups cause our system to fail every night, EBS backing has serious spiking problems, you can't access the replicas and it runs a shitty custom fork of MySQL
Thanks for the warning. I was pricing it out but was wary because of weird problems I've experienced with EC2 and inflexibility of ELB.
For what it's worth, I've used Postgres in production systems with great success.
For what it's worth, I've used Postgres in production systems with great success.
Postgres has had solid replication since 8.4
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...)
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...)
It doesn't do two way, you have to go to 3rd party addons for that.
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.
From the comments here though I'm not missing anything.
With dickey no less!
Aside from the lovely Link Bait article, imagine my surprise at seeing a '.xxx' domain on HN's front-page.
Hm, the first .xxx domain I've seen on HN and it's not even off-topic (although a little flamebaity).
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.
where does postgres need to catch up? and what knowledge gap?
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
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?
> 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?
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.
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.
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.
All RDBMS engines have a variety of features that are not necessary in all deployments.
I should've noted in the article, almost all of those are optional extensions to Postgres
Yes, I'm aware of that. I'm not sure how much it matters though. You still have to maintain backwards compatibility of both behaviour and api. (in case of external projects it may be less effort, but at the same time more danger that they get broken by accident)
MySQL support is fantastic - they offer optimization along with troubleshooting - and respond immediately. Also, they are relatively cheap as far as support goes.
I know MySQL.
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?
It's interesting that people are upvoting this submission, yet the comments are almost all calling it flamebait.
Wait, one box? What are clusters then?
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?
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.
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.
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.
A great example of this is MariahDB just provided a module to handle geospatial data in the database as well.
MariaDB
It took what, five years to fix the glaring design flaw where you couldn't use NOW() as the default in a datetime field. Seriously, this was just fixed a few weeks ago after years of outrage over it, and it was fixed by an outsider: http://bugs.mysql.com/bug.php?id=27645 Now we all get to wait for our hosts to update their MySQL installation, once the fix makes it into a release. How many more years will that be?
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 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.
Last time I checked, MySQL isn't governed by fate. What happened three years ago (or a year ago etc) has absolutely nothing to do with what the MySQL team does tomorrow in regards to improving the software.
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.
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.
We're talking about TURNAROUND TIME, not what happened years ago. This is something that took five years TO happen.
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.
The other problem is that every host offers MySQL. Not so with Postgres.
> Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine.
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.
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.
OK, then why shouldn't there be a special function to assess the cost of the beer in any specified currency at the time of the query?
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.
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.
except it doesn't, it's an optional extension
And yet conveniently cited as a feature of the database engine when it suits you.
> Where does this end?
With Erlang QLCs :)
With Erlang QLCs :)
> 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.
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.
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.
Yeah, I don't do that. I write the math expressions in the queries.