Обсуждение: How large can a PostgreSQL database get?
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?
Aleksey Tsalolikhin
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.
Thanks for all the great answers, folks, I'll pass this along.
Cheers!
Aleksey
On Wed, Apr 17, 2013 at 9:45 AM, 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.> --
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.
CFEngine Training:
New Jersey, Apr 29 - May 2. http://cf3.eventbrite.com/
New Jersey, Apr 29 - May 2. http://cf3.eventbrite.com/
New Jersey, May 3. http://lopsa-east.org/2013/lopsa-east-training/
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.