From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Michael Nolan <htfoot(at)gmail(dot)com> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Aleksey Tsalolikhin *EXTERN*" <atsaloli(dot)tech(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How large can a PostgreSQL database get? |
Date: | 2013-04-17 19:53:18 |
Message-ID: | CAOR=d=35B0cZqzb7qbQanYOArd7iW36NPgUUbxSzzv7Eb9Ekdg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Apr 17, 2013 at 12:53 PM, Michael Nolan <htfoot(at)gmail(dot)com> wrote:
> On 4/17/13, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | François Beausoleil | 2013-04-17 20:19:46 | Re: Most efficient way to insert without duplicates |
Previous Message | Bruce Momjian | 2013-04-17 19:49:29 | Re: Fetching Server configured port from C Module |