On Tue, Nov 17, 2009 at 6:33 PM, Jim Wright <jwri...@perelson.com> wrote: > Are there many companies in Utah using Postgres? I have been trying to > do a search for companies doing work with it on a large scale and have > only found a handful. Backcountry and EMC and a few others and that is > about it. Why aren't a lot of companies using it?
I have some thoughts on why it's not used more: - Market share. MySQL has more market-share. More beginning database admins are going to know about MySQL than they are about Postgresql. If you counted the database books at a local bookstore, I think those about MySQL would far outnumber those about Postgresql. And most of the books about PHP (another market-share leader) are likely going to have a chapter about accessing MySQL databases from PHP in them (and less likely to have a chapter about accessing Postgresql). MySQL has its own large O'Reilly conference (Google tells me Postgresql has its own conference, but I had never heard of it until now). - Replication. Unless things have changed drastically in the last year and a half (I haven't kept up with Pg much in that time period), setting up reliable and robust replication in Postgresql is nowhere near as simple as it is with MySQL. - Flexibility/Simplicity. MySQL is rather flexible when you stick with the basics. MyISAM is drop-dead easy to admin. It's (relatively) easy to back up, it's easy to schlep a 'database' from one machine to another when you need to, and so forth. That simplicity is probably a major reason why Omniture^WAdobe has MySQL (and not Postgresql) running on thousands of machines. - MySQL (for the reasons in the previous bullet point and more) has a less-demanding learning curve. All the above said, having admin'ed both in production environments, I find PG a much better designed database engine. In so many ways, it just feels better-engineered. I attended the MySQL conference this year, and was dismayed to see entire companies built around offering solutions to the headaches inherent in scaling MySQL. Sessions about running multiple instances of MySQL on a single box because MySQL can't scale well beyond a few cores. Having said that, my mantra is 'all databases stink, some just stink more than others.' The major movement right now with NoSQL data stores like CouchDB and its associates is a testament to the fact that traditional relational[sic] databases don't scale (well) to the massive amounts of data the likes of Google, Amazon, and Facebook are wrangling. I agree with Sasha--If you can find someone with good knowledge of the fundamentals of the relational model, data access, and database structures, someone who can tell you (for example) what the structure of a B-tree index looks like, why full-table scans, in some instances, are preferable to indexes, how to analyze and optimize queries (his/her first question should be along the lines of "What's this product's equivalent of EXPLAIN ..."), then with some ramp-up time (all db engines have their peculiar warts you have to learn about), you'll have someone who can do a good job with any database product you throw at them. OK, I've rambled enough. Time for bed. Best, Dan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
