Re: number of connections - Mailing list pgsql-general

From Christopher Browne
Subject Re: number of connections
Date
Msg-id d6d6637f0901190928y37006874w42c66410cc06e87e@mail.gmail.com
Whole thread Raw
In response to number of connections  (Rubén F. <rfs1986@gmail.com>)
List pgsql-general
On Mon, Jan 19, 2009 at 12:10 PM, Rubén F. <rfs1986@gmail.com> wrote:
> First of all, excuse my english...
>
> I have a doubt. I am designing a program for manage CV's. This program
> connect with a PostgresDB. This program will be used for 5,000 persons
> becaus it will be used in a University. Then, ¿how many actives connection
> could be postgres? ¿does it support a very big cuantity of information?
>
> Possibly, in the future, the program will grow up with more information and
> more users. ¿can i use in this case postgres?¿has it a good scalability?

We have database servers where the PostgreSQL instances are configured
to support on the order of a thousand concurrent connections, and
definitely have hundreds active at a time fairly frequently, so that
kind of scalability is certainly possible.

To support that, we have rather powerful hardware; that's not running
on "a cheap PC with an IDE disk drive."

It would actually be pretty unusual for the sort of application you
are describing to actually require thousands of concurrent
connections.  There may be thousands of users accessing the
application, but the database access is likely to be sporadic.

Web application frameworks typically offer support for "connection
pools" so that a much smaller number of actual database connections is
used to support a large number of users.

As for quantity of data, any respectable database can store very large
quantities of data.  "Many gigabytes" should be easy.  Terabytes are
where the challenges begin, but there certainly are organizations
using PostgreSQL to support terabyte-sized databases.
--
http://linuxfinances.info/info/linuxdistributions.html
Katharine Hepburn  - "Death will be a great relief. No more interviews."

pgsql-general by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: left join with smaller table or index on (XXX is not null) to avoid upsert
Next
From: Richard Huxton
Date:
Subject: Re: How can I look at a recursive table dependency tree?