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 <[email protected]> wrote: > > > On 8 Oct 2026, at 09:05, kavya chandren <[email protected]> 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. > >
