Comments on: What are the best choices for scaling Postgres?

By: Cory Isaacson

Cory Isaacson — Wed, 02 Jun 2010 16:23:15 +0000

Our dbShards product can in fact help with this. We use a concept called virtual shards that let’s you split a shard when further scalability is required. Check out the link to learn more:

http://www.codefutures.com/dbshards

By: jt

jt — Thu, 20 Aug 2009 18:20:58 +0000

It depends on how they want to scale out. They could have gone with Enterprisedb and used InfiniteCache. InfiniteCache is based on memcached and you can scale out memory to as many servers as you want. So you get one giant data buffer cache, essentially caching the whole database.

But if 8.4 feature set was a no go, then stick with standard Postgres and go with PL Proxy. Here’s some more info on that:
http://highscalability.com/tags/pl-proxy

That is what Skype does.

By: Log Buffer #156: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #156: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 31 Jul 2009 22:33:25 +0000

[...] Monash of DBMS2 asks, what are the best choices for scaling Postgres? “I have a client who wants to build a new application with peak update volume of several [...]

By: Fazal Majid

Fazal Majid — Fri, 31 Jul 2009 09:13:43 +0000

Not to start a flame war, but I don’t find MySQL any easier to install than PostgreSQL (or less so). Then again I insist on building from source myself on Solaris. Postgres is also easier to administer, and I much prefer pgAdmin to phpMyAdmin.

I suspect a big reason for MySQL’s popularity stems from the fact it used to be bundled with PHP. That, combined with its multithreaded architecture, which scales down well on low-end machines, even if it hits a performance wall on larger configurations.

By: Zman

Zman — Fri, 31 Jul 2009 04:14:07 +0000

I haven’t used this product but you might want to take a look at CodeFuture’s dbShards

Continuent’s Tungsten’s Enterprise might also work for you. I’m referring to the “Parallel replication to support sites with high write rates and/or sharded data sets” feature

I have no first-hand experience with either so this falls under the thought category not the experience one

By: Curt Monash

Curt Monash — Thu, 30 Jul 2009 18:38:18 +0000

I don’t think anybody focused in time on making PostreSQL easy to download and install. Packaging was a huge part of why MySQL got ahead.

By: Peter

Peter — Thu, 30 Jul 2009 18:22:43 +0000

Just wondering. I went to a Jobnob Happy hour yesterday. Most of the startups go the LAMP route. Why is there no LAPP stack? I wonder – since Oracle has their hands MySQL shouldn’t it be called LAOP – or OLAP because the big always comes first?

So are there any reason for not having a LAPP?

By: Curt Monash

Curt Monash — Thu, 30 Jul 2009 14:51:23 +0000

Therein lies a tale about the real value consultants bring. A big part is “You know, that’s an interesting question you hired me to answer, but there’s actually a much more important one that needs answering too …”

Beyond that, my learning doesn’t stop when the consulting project begins.

By: Michalis

Michalis — Thu, 30 Jul 2009 11:54:31 +0000

So, you’re actually asking your readers for what your client is paying you for..?

By: Curt Monash

Curt Monash — Thu, 30 Jul 2009 03:27:27 +0000

They’re not optimized for OLTP. Indeed, I’m not sure one gets much benefit from the parallelism in those systems if one’s doing transactional updates.