Live data from Hacker News

It's the Postgres Age

dickey.xxx

11–20 of 48 posts

Re: It's the Postgres Age

#15
"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.

Re: It's the Postgres Age

#16
post #6

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.

Re: It's the Postgres Age

#17
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.

Re: It's the Postgres Age

#18
post #9

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.

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.

MariaDB

Re: It's the Postgres Age

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

Post reply on HN