Postgres in Utah
danhanks at gmail.com
Sat Dec 5 00:38:43 MST 2009
On Tue, Nov 17, 2009 at 6:33 PM, Jim Wright <Jwright at 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
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.
More information about the PLUG