Re: Challenges with huge postgresql deployments in 300+ TBs

From: kavya chandren <kavyachandren(at)gmail(dot)com>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Challenges with huge postgresql deployments in 300+ TBs
Date: 2026-10-08 11:09:30
Message-ID: CAPXWBGYTazf_an=81Hn-BOCOz6x8giYU96A4b9RwbitSvswabw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Alban for your inputs around migration. My major concern was around
operational challenges (if any) for such huge database

On Thu, Oct 8, 2026 at 3:39 PM Alban Hertroys <haramrae(at)gmail(dot)com> wrote:

>
> > On 8 Oct 2026, at 09:05, kavya chandren <kavyachandren(at)gmail(dot)com> wrote:
>
> (…)
>
> > 6. Finding equivalents of oracle items (which is common during any
> oracle to postgres migration)
>
> There are a number of key differences between Oracle and Postgres that I’m
> aware of. This is by no means an exhaustive list, nor may it still be very
> accurate today; The last version of Oracle I worked with was Oracle 12i, so
> things may have changed.
>
> - Oracle doesn’t (did not?) differentiate between '' and NULL, while
> Postgres does. Make sure you get the right values in the right places.
> Safest bet is probably to import your data using column types in PG that
> allow for '’-values, so that you don’t get interrupted by errors from NOT
> NULL constraints and the like, and fix those later. That’s probably less of
> a hassle (even with 300+TB) than trying to correct the data beforehand.
>
> - Oracle has CLOBs, where you can dump those values in a (type) text field
> in PG. That may introduce a character encoding though, on which some values
> could fail if you don’t take care of those beforehand.
>
> - Oracle has BLOBs, where PG has a separate LOB table or bytea fields.
> Either approach has its cons and pros.
>
> - Old Oracle DDL may still contain CONNECT BY PRIOR recursion. PG uses
> recursive CTE’s.
>
> - Space-padded strings (CHAR(n)) in Postgres are supported, but they are
> usually advised against. Both performance and practical use of VARCHAR(n)
> are much better, with no practical benefits for CHAR(n). That is, apart
> from formatting monospace text output without processing (console style
> output or matrix printers and the like).
>
> Alban Hertroys
> --
> If you can't see the forest for the trees,
> cut the trees and you'll find there is no forest.
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2026-10-08 11:09:47 Re: Challenges with huge postgresql deployments in 300+ TBs
Previous Message Alban Hertroys 2026-10-08 10:09:31 Re: Challenges with huge postgresql deployments in 300+ TBs