Thread: How large can a PostgreSQL database get?

On 04/17/2013 06:23 AM, Aleksey Tsalolikhin wrote:
> Hi.  I was promoting PostgreSQL to an AIX/Oracle shop yesterday, they
> are looking to switch to open source to cut their licensing costs, and
> was asked how large a database does PostgreSQL support?  Is there an
> upper bound on database size and if so, what it is?

For a guide to capacities see:

http://www.postgresql.org/about/

Of course the above depends on resources allocated.

>
> Aleksey Tsalolikhin
>


--
Adrian Klaver
adrian.klaver@gmail.com

On Wed, 17 Apr 2013 08:23:41 -0500, Aleksey Tsalolikhin
<atsaloli.tech@gmail.com> wrote:

> Hi.  I was promoting PostgreSQL to an AIX/Oracle shop yesterday, they are
> looking to switch to open source to cut their licensing costs, and was
> asked how large a database does PostgreSQL support?  Is there an upper
> bound on database size and if so, what it is?

According to yahoo...:

http://glinden.blogspot.com/2008/05/yahoo-builds-two-petabyte-postgresql.html

...pretty big. But yahoo threw some programmers at it, I believe.

Straight out of the box? Not sure, but I'd expect many on this list have
databases larger than "enterprise oracle" shops.

On Wed, Apr 17, 2013 at 06:23:41AM -0700, Aleksey Tsalolikhin wrote:
> Hi.  I was promoting PostgreSQL to an AIX/Oracle shop yesterday, they are
> looking to switch to open source to cut their licensing costs, and was asked
> how large a database does PostgreSQL support?  Is there an upper bound on
> database size and if so, what it is?

Well, anything over hundreds of gigabytes is going to require tuning,
and above a terrabyte is going to require partitioning.  There isn't a
hard limit, but we don't see many serves over tens of terrabytes.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Aleksey Tsalolikhin wrote:
> Hi.  I was promoting PostgreSQL to an AIX/Oracle shop yesterday, they are looking to switch to open
> source to cut their licensing costs, and was asked how large a database does PostgreSQL support?  Is
> there an upper bound on database size and if so, what it is?

There is no real upper bound.

I think that backup will be a limiting factor, and you'll want backups.
Of course, sequential scans of really large tables will be very
painful, but that's the same for all database systems.

Yours,
Laurenz Albe

My experience, doing production and dev dba work on both postgresql
and oracle, is that either works well, as long as you partition
properly or even break things into silos. Oracle isn't magic pixie
dust that suddenly gets hardware with 250MB/s seq read arrays to read
at 1GB/s, etc.

With oracle partitioning is easier, and everything else on the
freaking planet is harder.

On Wed, Apr 17, 2013 at 8:15 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
> Aleksey Tsalolikhin wrote:
>> Hi.  I was promoting PostgreSQL to an AIX/Oracle shop yesterday, they are looking to switch to open
>> source to cut their licensing costs, and was asked how large a database does PostgreSQL support?  Is
>> there an upper bound on database size and if so, what it is?
>
> There is no real upper bound.
>
> I think that backup will be a limiting factor, and you'll want backups.
> Of course, sequential scans of really large tables will be very
> painful, but that's the same for all database systems.
>
> Yours,
> Laurenz Albe
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



--
To understand recursion, one must first understand recursion.

On 4/17/13, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> My experience, doing production and dev dba work on both postgresql
> and oracle, is that either works well, as long as you partition
> properly or even break things into silos. Oracle isn't magic pixie
> dust that suddenly gets hardware with 250MB/s seq read arrays to read
> at 1GB/s, etc.
>
> With oracle partitioning is easier, and everything else on the
> freaking planet is harder.


Scott, thank you for the best laugh I've had all day!

I started out on Oracle (some 20 years ago) and have been running both
MySQL and PostgreSQL databases for the last 10 years or so.  I'd take
PostgreSQL over the other two in a heartbeat!

Data integrity/data preservation issues (backup is just one aspect of
that) are going to be your biggest problems with VERY large databases,
no matter how much money you throw at it.
--
Mike Nolan

On Wed, Apr 17, 2013 at 12:53 PM, Michael Nolan <htfoot@gmail.com> wrote:
> On 4/17/13, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> My experience, doing production and dev dba work on both postgresql
>> and oracle, is that either works well, as long as you partition
>> properly or even break things into silos. Oracle isn't magic pixie
>> dust that suddenly gets hardware with 250MB/s seq read arrays to read
>> at 1GB/s, etc.
>>
>> With oracle partitioning is easier, and everything else on the
>> freaking planet is harder.
>
>
> Scott, thank you for the best laugh I've had all day!
>
> I started out on Oracle (some 20 years ago) and have been running both
> MySQL and PostgreSQL databases for the last 10 years or so.  I'd take
> PostgreSQL over the other two in a heartbeat!
>
> Data integrity/data preservation issues (backup is just one aspect of
> that) are going to be your biggest problems with VERY large databases,
> no matter how much money you throw at it.

Good points. No matter what db engine you're using, whether it's super
fast transactional systems, monstrous data mining systems, or 24/7
can't ever go down dbs, data integrity, hardware acceptance,
monitoring, and disaster recovery are the most important subjects to
be proficient in. Now some db engines do nothing but get in your way,
but both postgresql and oracle seem to be reasonably good platforms
for largish deployments, say a few terabytes, without a lot of
futzing. After that planning becomes king. You're never gonna just
deploy a single server with 100 petabytes storage and expect it to
scale.