Live data from Hacker News

PostgreSQL Rising

wekeroad.com

81–90 of 204 posts

Re: PostgreSQL Rising

#82
post #61

Earlier quoted context omitted.

It's not a matter of drop-in portability, it's a matter of reducing the complexity of migration as well as developer confusion. Often the case for using custom data types, for example, is quite weak, when considering the tradeoffs. They move complicated logic into the database, are unfamiliar to most developers, and end up needing to be reverse engineered if you want to move your data into different storage. I think…

"it's a matter of reducing the complexity of migration" You put the code in your application so you can switch out the database, but why do you want to switch databases? You can't switch out the database for one with more features, because then you're not using the lowest common denominator any more, and you can't switch back. It can't be licensing costs, because postgresql licenses are free. The only other reason I…

One reason if you are building a shippable product that needs to work with a variety of client databases rather than a choice of your own.

99% of the time, this is why you build DB agnostic apps.

Re: PostgreSQL Rising

#83

I think the reason that MySQL became more popular than PostgreSQL is because it did one thing really good: It was a very fast file access daemon. PostgreSQL tried to do too much, ended up not doing any of it very well especially in the area of performance and didn't become as popular. Maybe useful to remember this going forward.

I see it as a major success story.

Postgres was developed over a long period of time with careful attention to architecture, robustness, and extensibility. It also focused on both external and internal documentation and cleanliness. And, it followed the traditional database system model with a cost-based optimizer and everything else.

As a result, we see a very robust developer community. It's a real machine -- churning out high quality releases every year with a great mix of newsworthy features. Enterprises and startups alike are flocking to postgres for a huge variety of use cases.

Slow and steady wins the race (and it doesn't hurt to be 5 tons and have tusks) and isn't tired afterward. And in databases, it's good to play for the long term because that's how long the data will last.

I wouldn't trade that for some first-to-market popularity.

Re: PostgreSQL Rising

#84
The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons.

So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason to want less strictness, the ones that know how and when to change the settings, and the ones that just don't give a fuck.

You're not going to convince the latter until you are #1, and you're insulting the intelligence of the first two, whilst also making them question whether the arguments in favor of Postgres are actually true, since you're not being particularly honest in your criticism of MySQL.

And you're wondering why Postgres doesn't get any more love?

Most MySQL users are well aware that Postgres is technically a better DB. They mostly (right or wrong) feel MySQL serves their needs sufficiently, and are not particularly attracted to an open source community with such a douchy attitude.

If even Oracle doesn't scare people of sufficiently to jump ship and switch to a better, free and open database, you've got a serious image problem. Stop blaming it on other people's "stupidity".

Re: PostgreSQL Rising

#85
post #79
post #74

Earlier quoted context omitted.

In my experience you don't want to provide X as a service based on a third party closed product (meaning: anything not open source & open community).

I imagine you don't do business in the enterprise world.

Yes, I do. I said "in my experience" and I totally understand why Heruku is offering PostgreSQL and not DB2, Oracle or SQL Server as a service.

Amazon RDS started with MySQL, and only two years later Oracle support was added. SQL Server three years later.

Re: PostgreSQL Rising

#86

I'd love to move away from Oracle to Postgres, I really would. I'm trying to. But for massive amounts of data the partitioning and some other features of Oracle just work better. The partitioning is a huge thing, especially for our data which is partitioned by week then organized according to a hierarchical triangular mesh with bitmapped indexes. This works so well for us (at 8 billion rows) it's silly. MySQL couldn'…

If you'd like to give Postgres a serious shot, I'd recommend taking a look at Citus: http://citusdata.com/. It's a distributed database forked from Postgres, and can easily handle billions of rows in realtime for certain use-cases. We use it at MixRank to store and run analytics on for ads we crawl in the internet (a respectable amount of data), and it handles extremely well. (Full disclosure: I know the Citus team well).

I've also pushed Postgres to its limits and suspect you'd be able to make it work with that much data, though I wouldn't consider it a trivial exercise executing that transition on a production system. If you're seriously considering it though, feel free to reach out via the email in my profile.

Re: PostgreSQL Rising

#87
post #26

What are the scaling differences between MySQL and PostgreSQL? That's the main reason we haven't shifted and we have a new project coming up that I've been interested to use PostgreSQL with as one our developers prefers it, but are we opening a whole new can of worms on that front?

"What are the scaling differences between MySQL and PostgreSQL?"

The best advice I have is that using a different database system, particularly ones as different as MySQL and PostgreSQL (which are essentially opposites) is like going to a foreign country. You'll find things you like and things that you don't like, and it will have a real impact on your quality of life, but it's hard to say in a few words the things that will really matter to you. You don't have time to live in every country in the world, but you owe it to yourself to at least visit a few that come highly recommended.

Whatever you do, don't try to make the new country into your old country. You will just be disappointed.

The same goes for database systems.

Re: PostgreSQL Rising

#88

Earlier quoted context omitted.

"it's a matter of reducing the complexity of migration" You put the code in your application so you can switch out the database, but why do you want to switch databases? You can't switch out the database for one with more features, because then you're not using the lowest common denominator any more, and you can't switch back. It can't be licensing costs, because postgresql licenses are free. The only other reason I…

One reason if you are building a shippable product that needs to work with a variety of client databases rather than a choice of your own. 99% of the time, this is why you build DB agnostic apps.

The main reason to do that is licensing. You either need to get a redistribution license, or the client needs to work out their own licensing deal -- and either way, you don't want to be beholden when negotiation time comes.

That also applies to MySQL, because it's GPL.

That does not apply to Postgres, because you can just ship it with the app.

I exaggerated a little, there certainly are times when you just don't care what database system you use and would rather have simple migrations at the expense of owning more code. But I think these reasons are weighted much too highly, particularly in the context of postgres.

Re: PostgreSQL Rising

#89
I had to use Postgres at a job or about 6 months and hated it due to lack of a decent GUI. The "official" one has many bugs and quirks and takes quite a bit of getting used to especially after coming from phpMyAdmin. So it's nice to see there is now an .app for it.

Re: PostgreSQL Rising

#90
post #84

The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons. So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason…

> usual target is some default settings

for me it would be missing common table expressions, weak implementation of functions and SPs (recursion) and horrible .NET connector (connections dying, int can get returned as byte[]). And I'm not even mentioning the gazillions of advanced features that pgsql (and Oracle or SQL Server) has that mysql doesn't.

Post reply on HN