Large databases (& PostgreSQL)

[Michael Paoli]

If you haven't already, you may want to check with some more specific
PostgreSQL resources.  BALUG[1] had a presentation on PostgreSQL not all
that horribly long ago.  There are also PostgreSQL Users Groups[2] that
may also be quite helpful/useful.  I'd think it likely that there are
quite large PostgreSQL databases out there, and including transactional
and/or other high I/O utilizations.  Anyway, such resources might be
able to point to information on what is and isn't presently feasible with
PostgreSQL for such large databases, and perhaps also
answers/suggestions/tips on some or many of the problems/challenges
typically encountered with PostgreSQL on such large databases.

Although it might be the case that PostgreSQL and/or other pure Open
Source solutions may not cover everything in an existing proprietary
configuration, I'd certainly hope, and think it likely, that Open
Source solutions would well cover much, or perhaps all of that, though
not necessarily in quite the same way (e.g. there typically are the issues
of proprietary non-standard features that are in use, and sometimes
Open Source may come to fill a particular need relatively late in the
game if the niche for that particular need is rather to quite small).

references/excerpts:
1. http://www.balug.org/
(some of BALUG's list stuff and archives are in semi-broken state
at the moment so ...)
http://www.google.com/search?hl=en&lr=&q=site%3Abalug.org+postgresql
2. http://pugs.postgresql.org/
http://pugs.postgresql.org/sfpug/

Quoting Jared Rhine <jared@wordzoo.com>:

>   Sean> Lastly Jared was talking about how Debian is great where he
>   Sean> works, the trials and tribulations of 20 terabytes of data,
>   Sean> postgres v. oracle, etc.
> 
>   Alvin> what are the problems with the 20TB of data ( db ) ?
> 
> Clarifying: I was not discussing how to run a 20TB (actually 60TB)
> database on Debian.  Instead, I was saying how I was somewhat humbled
> in my current position because I couldn't offer any realistic
> lean/mean/open-source way to replace our current 60TB Oracle database.
> 
> I also said I have yet to find any reference to anyone anywhere
> running a transactional database this large on an open platform.
> 
> Usually, I can offer ways to distribute, redesign, or otherwise
> simplify a multi-million dollar "big iron" installation.  But instead,
> I'm mostly shutting up and saying, "Well, Oracle+Sun+SAN is a pretty
> good solution here".
> 
> The boxes still go down, and we can blame every vendor in the mix
> above for some downtime, but there's no way I know of to migrate to
> improve costs while maintaining performance on this transactional
> system.