Seconding #postgres as awesomely smart and helpful. Especially RhodiumToad, who always seems to be in there.

Oh man, RhodiumToad on #postgres totally saved my ass a couple of times like 2 years ago. Good times.

I see this #whatever notation a lot. What does it refer to?

irc chat, generally on the 'freenode' irc server - http://freenode.net/

Wow, really? Chat? In 2010??? That would never have occurred to me. Thanks!

IRC is still heavily used in the open source world. It's a great resource and you should add it to your arsenal of 'places to get support on FLOSS stuff'

Should we be doing video chat in 2010? People used telephones 30 years ago, and it's still popular now :-)

I'm on irc most days of the week. It's far from dead.

#whatever in the context of a 'channel' means IRC (Internet Relay Chat), generally on the Freenode.net network.

Agreed. It's like saying they should have written Quora using C# because there are more developers for it instead of a "fringe" language like Python.

My guess is that a small ecosystem is bad for pretty much everything other than databases:

- Programming languages have libraries

- Frameworks have plugins

- Operating systems have compatibility issues

The best code is the code you don't have to write.

There are a lot of "positive network externalities" in the computer world: the more people use something, the more valuable it is. That's true for databases as well.

However, what he's saying is that beyond a certain point, those effects tend to become a bit less important. Java is more popular than Python, for instance, but you can get pretty much anything done that you need to in Python. OTOH, a language like Erlang (sorry to pick on it, it's just an example) is still fringe enough that there are gaps in its libraries, it's tough to find people, and so on.

Echoing your point, having a library that can do something is fantastic. Having two is even better when you have a choice on which one feels more comfortable to use and is more suited for your project. Having 25 libraries that do basically the same thing gives diminishing returns because the community is split over which one is better and easier to use, while the majority won't be full featured and with a larger number of bugs overall.

This is not necessarily a black and white scenario that holds true to everything, however. There is no such thing as an absolute generic.

That's really interesting to know, actually. I've only been with companies that had MySQL installations (Facebook and Twitter) and so jumping in was really easy, but on the other hand I do like to do things right. A few questions, though:

0/ How would I be able to tell if the limitations of our DB are because of MySQL and would be solved by PostgreSQL? That is, common pain points in MySQL that we wouldn't recognize immediately until we switched? (Edit: mostly looking for performance-related, but anything is fine.)

1/ Is there a PostgreSQL consulting firm that has the same reputation that Percona does with MySQL?

2/ Is there a good place to start when there's an issue or question I have with PostgreSQL (aside from IRC)? With MySQL I've been either going to the docs, or to Google, but it's been spotty with either.

0: Empact lists a few here: http://news.ycombinator.com/item?id=1547192

1: There are a number of highly trusted PostgreSQL consulting firms; the last time my employer needed a consultant, we hired one from Fujitsu's dedicated PostgreSQL team.

2: So far, I've only needed the (deliciously comprehensive) PostgreSQL online docs and (sometimes) Google; most Google searches wind up on the official user/developer mailing-lists, so that would be another good place to ask.

http://www.postgresql.org/support/professional_support is good place to look for consulting firms.

Both http://www.pgexperts.com/ and http://www.enterprisedb.com/ are run by core PostgreSQL developers.

for the consulting firm question http://www.enterprisedb.com/ and http://www.commandprompt.com/ are large contributors to postgres and have great mindshare in the community

re 2: The mailing lists http://www.postgresql.org/community/lists/ are a good place to ask questions. Core devs are frequently answering questions there.

Maybe the postgres supporters can fill this in about Postgres reliability:

http://www.quora.com/How-reliable-is-Postgres-replication

that's one of the biggest issues scaring people away from Postgres.

The replication is reliable, it's just that with the 8.0 releases, it's an add-on and not obvious to setup (e.g with Slony have to do special procedures to properly replicate DDL changes, it required having triggers on replicated tables, etc). In 9.0 replication is built in, transparent, and trivial to setup.

Sorry, but pre-9.0, Postgres replication is neither reliable nor easy to setup/admin. It's absolutely the worst thing about (pre-9.0) Postgres, and I'm glad the core team finally caved and made it a first-class feature.

Slony caused us no end of problems (large postgres installations at Last.fm). It's a monumental pain in the ass, it will choke on something, probably when you're trying to make a DDL change, sometimes just at random. Docs/help on trying to figure out what went wrong and how to fix the replication are not easy to find. After you managed to 'fix' it, you will be unsure if the slave is truly in sync. The only way to be confident is to nuke the slave and start over to ensure you have a consistent replica.

That said, I'd still gladly suffer the trials and tribulations of crappy trigger based replication than use MySQL.

I'm looking forward to trying replication in 9.0, it sounds fantastic.

You are correct about Slony but if you do not care about doing any reads at the slave in pre-9.0 you had log shipping and warm standby. Warm standby is perfect for using the slave for failover in case the master crashes or the HDDs break.

Warm standby is very reliable and easy to admin. The setup is not that easy but not too hard either.

nicely articulated, couldn't agree more