I just attended the Keynote by Joshua Drake from Command Prompt. There are a lot of good movements on the operational organization of the PostgreSQL community. I think his vision of the community is more aggressive and structured than many are prepared for, but in a community as large as the PostgreSQL community it is very good to have someone pushing the envelope and attempting to apply a vision. I don't want to go as far as Josh wants to do, but we'll wind up part of the way there and that "just perfect."
He used a lot of geek marketing terms going so far as to use the term "Db 2.0." I'll add a few comments and marketing terms to my commentary. Josh said we need to stop following and start leading; stop looking at features in Oracle as a future feature map. What Josh means here is that we need to be disruptive. We need to implement things no one else has. I think we need both.
Josh said he wanted everyone using PostgreSQL and not "the Dolphin." I have to say that I think his statement was too strong to match my opinion. I like PostgreSQL. I believe it is the right tool for the job more often than not. However, there is a "not." In fact, there are a lot of "not"s. There are many requirements that, when explored, map better to the offerings of an Oracle, a DB2, or, dare I say, even a MySQL. MySQL is the "right tool for the job" for many requirements. There is room for more than one database. In fact, there is room for all databases. Good business and engineering practices should always define the process of evaluating technology appropriateness. One good business practice is placing only technology that can be well supported by your existing (or easily accessible) engineering talent. This practice should never be confused with evangelism and zeal -- we all have these character traits, but good engineers and managers shouldn't use them as a part of defining the appropriateness of a solution.
Josh's primary goal seems to be to grow the community which will better legitimizes PostgreSQL. The one thing I took away from this is that I should make sure PostgreSQL is a more common topic of discussion. I think we should start a Baltimore/Washington PostgreSQL User Group; OmniTI will provide facilities, coordination and even food and drink as long as it is under thirty people.
I'm sitting at PostgreSQL Conference. I have a snazzy slide set. I have forgotten my Mac 15" VGA adapter. @#$^ *@#$*%! I'm sure I'll be able to borrow an adapter from someone, but I must note that this conference has a much smaller Mac to PC laptop ratio than any other other conference I've been to in the last two years. (a.k.a. a large group in denial).
Tuesday, April 1. 2008 at 13:45 (Link) (Reply)
Hi Theo,
Nice post. Just a quick question: I agree that one should evaluate the requirements of a project before selecting a database back end, but I was wondering what sort of requirements demand MySQL over PostgreSQL? Other than developer familiarity, I can't myself think of one. I can think of when I'd rather use SQLite than PostgreSQL, but never MySQL. But I expect that's because I've just never run across the requirements that screamed "MySQL!" So I'm just curious, can you give some examples of requirements that better map to MySQL?
—Theory
Tuesday, April 1. 2008 at 17:35 (Link) (Reply)
Something with very high read:write demands that requires 50 replicas. That's just simple to manage using MySQL and a PITA with PostgreSQL. Also, if everything you do it auto-commit and every query is returned as a single row via a PK-based execution -- it is very likely that MySQL will outperform PostgreSQL. There are many apps like that.
Tuesday, April 1. 2008 at 17:53 (Link) (Reply)
Theo,
Yes, I suppose there are apps written like that. Sounds awful. I'm glad I haven't had to deal with any of them (thus far).
So, the short answer to my question is:
* When you need lots of replicas, 'cause they're easy in MySQL
* When you have a poorly-written application.
Why would anyone need 50 replicas?
—Theory
Tuesday, April 1. 2008 at 23:04 (Link) (Reply)
Having a database where all of the transactions are single command (auto-commit) and have tight, PK-based, single-row lookups has nothing to do with bad design. It has to do with application requirements. Some apps need that behavior, some don't.
As for 50 replicas. Say you can do 10k queries/second on one box, but you need to do 350k queries/second. I want 50 replicates running at 7k queries/second to achieve capacity and maintain a max of 70% utilization.
Tuesday, April 1. 2008 at 14:36 (Reply)
I was pleasantly surprised at how many laptops besides my own I saw running Ubuntu at the conference. It's completely reasonable to use a cheap PC laptop + Ubuntu as a platform nowadays for some things.
Wednesday, April 2. 2008 at 12:40 (Link) (Reply)
Thanks for the feedback Theo. Not sure what else to say.... :P
Thursday, April 3. 2008 at 20:59 (Link) (Reply)
You're welcome. In case it wasn't clear, I very much enjoyed your kick-off of the conference. You played an enormous part in the success of PostgreSQL Conference East and it went spectacularly. Awesome and thanks!