Migrating from Oracle Exadata to PostgreSQL

Leaving the Appliance, Not Just the Database

Migrating from Oracle Exadata to PostgreSQL is a different exercise from a plain Oracle-to-PostgreSQL move, and the difference is hardware. Exadata is Oracle Database running on an engineered system whose storage tier does real database work — so the migration isn’t only about schema and PL/SQL, it’s about reproducing on commodity infrastructure the performance that a purpose-built appliance was giving you. Plan for that up front and the move is smooth; ignore it and you’ll ship a correct migration that feels slow.

What Exadata Actually Gives You

Most of Exadata’s speed comes from features that push work down to the storage cells rather than from the SQL layer:

• Smart Scan — filtering and column projection happen in the storage tier, so only relevant rows travel to the database node.
• Storage Indexes — in-memory min/max maps that skip storage regions that can’t match a predicate.
• Hybrid Columnar Compression (HCC) — high-ratio columnar compression for warehouse-style tables.
• Flash cache & fast interconnect — NVMe-class latency and high-bandwidth links between compute and storage.

What Changes When You Leave the Appliance

PostgreSQL has no equivalent of a smart storage cell — it reads blocks and does the filtering in the engine. The good news is that the workloads Exadata accelerates are exactly the ones PostgreSQL has strong, if different, answers for. The migration mindset is: for each Exadata feature you relied on, choose the PostgreSQL technique that reproduces the effect.

• Smart Scan & Storage Indexes → declarative partitioning for partition pruning, plus BRIN indexes on naturally ordered columns (dates, IDs) to skip large ranges cheaply.
• HCC → PostgreSQL’s TOAST compression for wide rows, and columnar storage via an extension when a table is genuinely analytical.
• Parallelism → PostgreSQL parallel query for large scans, joins, and aggregates — tune max_parallel_workers_per_gather to match your core count.
• Flash cache → provision NVMe storage and a generous shared_buffers/effective_cache_size; modern SSDs close much of the raw-latency gap.

Sizing the Target Honestly

HCC can make an Exadata footprint look small on disk. When you migrate, uncompressed (or TOAST-compressed) PostgreSQL data can need more space, so size storage from real, uncompressed row sizes rather than the Exadata number. Budget memory for the working set you want cached, put the hottest tables on the fastest storage, and lead with partitioning on the big fact tables so pruning does the heavy lifting Smart Scan used to.

The Migration Itself

Once the performance plan exists, the mechanics are the standard Oracle-to-PostgreSQL pipeline — assess the schema, convert DDL and PL/SQL, bulk-load the data, validate, and cut over with change data capture. Nothing about Exadata changes the conversion; it only raises the bar on the target design. See our partitioning guide for the pruning patterns that most directly replace Smart Scan.