Re: I need your help to get opinions about this situation

Rayner --

<...>
> I have a database of 1000 tables, 300 of theirs are of major growing
> with 10000 rows daily, the estimate growing for this database is of
> 2,6 TB every year.

In and of-itself sheer number of rows only hits you when you need to be
reading most of them; in that case good hardware (lots of spindles!) would
be needed for any database.

> There are accessing 5000 clients to this database of which will be
> accessed 500 concurrent clients at the same time.

That could be too many to handle natively; investigate pgPool and similar tools.

> There are the questions:
> 1. Is capable PostgreSQL to support this workload? Some examples
> better than this.

Depends on the native hardware and the types of queries.

> 2. It is a recommendation to use a cluster with load balancer and
> replication for this situation? Which tools are recommended for this
> purpose?

Depends on what you mean -- there is no multimaster solution in postgreSQL
as far as I know, but if you only need one central servers and R/O slaves there
are several possible solutions (Slony as an add-on as well as the new
capabilities
in the engine itself.

> 3. Which are the hardware recommendations to deploy on servers? CPU,
> RAM memory capacity, Hard disk capacity and type of RAID system
> recommended to use among others like Operating System and network
> connection speed.

RAID-5 is generally a bad choice for databases. The specific answers to these
questions
need more info on workload, etc.

I migrated a fairly large Informix system to postgres a few years ago and the
main issues
had to do with postGIS vs. Informix Spatial Blade; the core tables converted
cleanly; the
users and permissions were also easy. We needed to use pgPool to get the same
number
of connections. This was actually a migration -- from Sun Solaris to Linux so
comparing
the two directly wasn't easy.

We moved "chunks" on the application and tested a lot; spatial data first and
the bookkeeping
and accounting functions and finally the warehouse and large-but-infrequent
jobs.

HTH,

Greg Williamson