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 the Postgres Age
21–30 of 48 posts
Re: It's the Postgres Age
#22did 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?
Re: It's the Postgres Age
#23The 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.
> 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.
Re: It's the Postgres Age
#24I 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…
I should've noted in the article, almost all of those are optional extensions to Postgres
Re: It's the Postgres Age
#25It's interesting that people are upvoting this submission, yet the comments are almost all calling it flamebait.
Re: It's the Postgres Age
#26"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.
Postgres has had solid replication since 8.4
Re: It's the Postgres Age
#27I 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?
Re: It's the Postgres Age
#28I 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…
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.
Re: It's the Postgres Age
#29I 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…
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)
Re: It's the Postgres Age
#30Puppet 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...