On Sat, 20 Oct 2007, snacktime wrote:
It's a web app that will be using ruby on rails. The challenge I'm running into is that the latest conventional wisdom seems to be that since obviously databases don't scale on the web, you should just not use them at all.
Those who don't use a DBMS to store data are doomed to reinvent one, poorly.
Ruby On Rails makes some design trade-offs that can make scaling a large database driven installation challenging. An article that greatly popularized the issues involved is the interview at http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/
There are a variety of workarounds for this though. Some people use memcached http://www.danga.com/memcached/ in various ways to reduce the work the database handles directly. There are Ruby-based approaches like http://magicmodels.rubyforge.org/magic_multi_connections/ that let you use a database cluster to scale higher.
On the PostgreSQL side, programs like PgBouncer let you reduce database-related overhead when it's the sheer number of physical connections dragging performance down https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer
The thing to observe here is that even should the database itself turn into a scaling bottleneck, there are several clever solutions that let you keep the good things about a proper RDBMS while providing higher throughput for the specific demands of the web application environment. Accordingly, focusing on the raw performance of PostgreSQL is kind of misleading. You shouldn't have to hit the database for everything if you put the right kind of layer on top.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
