Most SE2 exits to PostgreSQL are scoped as if you were leaving Enterprise Edition, and they are not. This is the honest inventory of what a Standard Edition workload depends on, what it never had, and where PostgreSQL replaces it for free.
Most SE2 exits to PostgreSQL are scoped as if you were leaving Enterprise Edition, and they are not. This is the honest inventory of what a Standard Edition workload depends on, what it never had, and where PostgreSQL replaces it for free.
The single most expensive mistake in an SE2 exit is scoping it as if you were leaving Enterprise Edition. In 25 years of migration reviews, I have watched teams budget for Partitioning conversion, Advanced Security key management, and Diagnostics Pack replacement, only to discover that none of those features were ever licensed under Standard Edition 2 in the first place. You cannot lose what you never had. An SE2 workload, by the strict definition of what Oracle permits under the license, runs on base features plus a small handful of things bundled into SE2 itself. That fact right-sizes the migration effort dramatically.
This page inventories what SE2 actually shipped with, what it lost in 19c, and what PostgreSQL replaces one for one. If you are still deciding whether to exit at all, start with the SE2 migration decision framework that lays out all three paths. If you have already decided PostgreSQL is the destination, this is the feature map you build the project plan against.
Oracle Standard Edition 2 cannot license a single Enterprise Edition option. Not as an add-on, not at any price. Partitioning, Advanced Security (including Transparent Data Encryption), Label Security, Database Vault, In-Memory, the Diagnostics Pack, and the Tuning Pack are all structurally unavailable to an SE2 database. This is not a discount conversation. The options either do not exist in the SE2 binaries or exist only in the limited base form Oracle bundles into the product.
The consequence for migration scoping is direct. If your source is genuinely SE2 and has stayed compliant, then by construction there is no Partitioning to convert, no TDE keystore to reproduce, no AWR baseline to port, and no Multitenant pluggable-database architecture to unwind. In our experience reviewing enterprise Oracle estates, Partitioning appears in fewer than 40% of Enterprise Edition databases, which means over 60% of EE workloads have no partitioning dependency at all. An SE2 workload sits in a stricter box than that: it was never permitted to have one. Your migration inventory shrinks accordingly.
You cannot migrate a feature you were never licensed to run. An honest SE2 exit is scoped to base features, not to the Enterprise wish list.
One caution before you assume a clean inventory. If Enterprise-only features were accidentally enabled on your SE2 estate, you have a back-license exposure problem that predates any migration decision, and it should be resolved before you talk to anyone at Oracle. We cover that specific trap in Enterprise features that sneak into an SE2 estate. Run the audit first. A migration does not erase historical non-compliance, and Oracle's LMS team will assess the running configuration, not your intent.
Oracle removed Real Application Clusters from Standard Edition starting with 19c. There was no deprecation phase and the notice was short, buried in the licensing documentation. The replacement is Standard Edition High Availability (SEHA), available from Release Update 19.7 onward. SEHA is a cold-failover, single-instance clustered configuration. It is not RAC. It has no global cache and no global enqueue, which means no active-active scale-out and no zero-downtime instance failover. We treat this in depth in the SE2 high-availability alternatives analysis and in the underlying Standard Edition RAC in 19c reference.
Why this matters for a PostgreSQL exit: if your SE2 database runs on 19c or later, your high-availability model is already cold failover or a third-party tool such as Dbvisit StandbyMP, not RAC. That is a materially lower bar to replace. PostgreSQL's built-in streaming replication with Patroni or repmgr for automatic failover delivers a comparable or better availability posture than SEHA, and it does so in the free core with no option purchase. If you were still on 18c or earlier and running SE RAC, the picture is different and you should map the cluster topology carefully before committing to a target design.
The table below maps the features an SE2 workload realistically uses to their PostgreSQL equivalents. The point of the exercise is to separate features SE2 genuinely shipped with (which you must replace) from Enterprise-only features (which are not in scope). Everything in the SE2 column below is either base functionality or bundled into SE2; nothing here requires an EE option, because SE2 cannot license one.
| Capability | SE2 reality | PostgreSQL equivalent (free core) | Migration effort |
|---|---|---|---|
| Physical replication / standby | No Data Guard on 19c; manual or third-party | Streaming (WAL) replication, built in since PG 9.0 | Low: native, well documented |
| Logical / table-level replication | Not available in base SE2 | Logical replication, PG 10 and later | Low to moderate |
| Automatic failover / HA | SEHA cold failover (19.7+), single instance | Patroni or repmgr, automatic | Moderate: cluster design and testing |
| Parallel query | Very limited under 16-thread cap | Parallel query in core | Low: often a performance gain |
| Partitioning | Not licensable in SE2 | Declarative partitioning in core | None: no source dependency |
| Encryption at rest (TDE) | Not available in SE2 | pgcrypto, filesystem or storage-level encryption | Low to moderate: design choice |
| Deep diagnostics (AWR/ASH) | Not available; basic tooling only | pg_stat views, pg_stat_statements, extensions | Low: retool monitoring |
| Optimizer | Adaptive plans (EE feature, not in SE2) | Cost-based optimizer, sufficient for most workloads | Moderate: index and plan review |
Read the third column carefully. The features an SE2 workload depends on (streaming replication, parallel query, basic diagnostics) are all present in PostgreSQL's free core, and the features it does not have because SE2 forbade them (Partitioning, TDE, AWR) are things you are not obligated to reproduce on day one. PostgreSQL's optimizer is not as clever as Oracle's adaptive plans, but for a workload that ran acceptably under SE2's 16-thread execution ceiling, it is sufficient. A skilled DBA tunes indexes and query plans to comparable performance. We say that from field experience, not from a benchmark you should quote in a business case.
SE2 limits each database to sixteen CPU threads of execution. This is not an audit rule. The database enforces it on itself, so you meet it as a performance ceiling rather than as a compliance finding. The practical implication for a migration is reassuring: any workload that ran happily inside SE2 was, by definition, constrained to sixteen threads of concurrent execution. That is not a demanding target for a modern PostgreSQL instance running current hardware.
If you were pressing against the 16-thread cap and feeling the pain, you were already a candidate to move off SE2 for reasons that have nothing to do with PostgreSQL. That story is covered in outgrowing the SE2 two-socket, 16-thread cap. The relevant point for migration sizing: PostgreSQL does not impose a thread cap. Moving a cap-constrained SE2 workload to PostgreSQL often produces a performance headroom windfall, not a regression, because you are removing an artificial ceiling.
SE2 lists at $17,500 per occupied socket, capped at two sockets, so the maximum SE2 Processor license is $35,000 per server at list. Named User Plus runs $350 per user with a 10-per-server minimum. On top of the license, support runs at 22% of net license fee every year, and across a five-year horizon that annuity quietly exceeds the license itself. That 22% recurring line is the number that actually justifies most PostgreSQL migrations, not the one-time license.
SE2 discount discretion is structurally tighter than Enterprise Edition. SE2 deals rarely reach Oracle's deeper discount tiers because the footprint does not justify the deal size, and the maximum practical band on a standalone SE2 purchase is 35% to 50%. That matters for two reasons. First, your SE2 spend is already close to list, so there is little room for Oracle to sweeten a renewal to keep you. Second, a credible PostgreSQL exit is leverage even if you choose to stay, because it gives you a walk-away alternative that the SE2 price point alone does not.
On a five-year horizon the 22% annual support annuity exceeds the license. That recurring line, not the one-time fee, is what a PostgreSQL exit removes.
The full financial model for the exit, including break-even timing and the cost of migration labor, lives in the PostgreSQL and Aurora business case. If you are weighing the exit against a straight upgrade instead, compare it to the socket-to-core repricing in the SE2 to Enterprise Edition upgrade cost math, because moving up to EE is frequently more expensive than moving off Oracle entirely.
The current PostgreSQL release is 18.4 (as of May 2026), and the mature migration tooling targets PostgreSQL 14 through 18. The workhorse tools are Ora2Pg 25.x for schema and data conversion, AWS DMS 3.5 and later plus its Schema Conversion for cloud-targeted moves, and pgLoader 3.6 for bulk data. These handle Oracle 11g through 23ai sources into PostgreSQL 14 through 18. Ora2Pg in particular produces a migration assessment report that estimates conversion difficulty per object, and you should run it early to get an honest scope.
The honest breakdown from field experience: for an SE2 source, roughly 70% to 90% of the schema converts automatically because there are no Enterprise options complicating it, and the residual effort concentrates in PL/SQL logic and application-layer SQL dialect. That is where the calendar time goes. The absence of Partitioning, TDE, and Multitenant, all forbidden under SE2, is precisely what keeps the conversion tractable compared with an Enterprise Edition exit.
Sequence the work in this order. First, audit your running configuration for accidentally enabled Enterprise features and resolve any exposure before you engage Oracle on anything, because a migration does not clear historical non-compliance. Second, confirm your actual HA model: if you are on 19c or later, you are already on SEHA cold failover or a third-party tool, which PostgreSQL's streaming replication and Patroni replace comfortably. Third, run Ora2Pg's assessment report to get an object-level conversion estimate rather than a guess.
Fourth, build the financial case on the recurring 22% support annuity across five years, not the one-time license, because that is the number that dominates the return. Fifth, whether or not you intend to leave, present the credible PostgreSQL alternative at your next SE2 renewal. The tight 35% to 50% discount band on standalone SE2 means Oracle has limited room to counter, and a documented exit path is the strongest leverage an SE2 buyer holds. The migration effort for a genuine SE2 workload is smaller than the market assumes precisely because Standard Edition never had the features that make Enterprise Edition exits hard.
Yes, and by a wide margin. SE2 cannot license any Enterprise Edition option, so Partitioning, Advanced Security (TDE), Label Security, Database Vault, In-Memory, and the Diagnostics and Tuning Packs were never present to migrate. Your PostgreSQL scope covers base features plus SE2-bundled functions only, which is why an SE2 exit is materially smaller than an EE exit.
Oracle removed RAC from Standard Edition in 19c and replaced it with SEHA, a cold-failover single-instance cluster. PostgreSQL offers built-in streaming (WAL) replication with Patroni or repmgr for automatic failover, all in the free core. For a workload already running SEHA or a third-party tool, PostgreSQL delivers a comparable or better availability posture without option costs.
SE2 never had TDE, since Advanced Security is an EE-only option. If your compliance obligation requires encryption at rest, you meet it in PostgreSQL through pgcrypto, filesystem-level encryption, or storage-level encryption. This is a design choice at the target, not a feature migration from the source.
For most SE2 workloads, yes. Oracle's optimizer has smarter adaptive plans and plan management, but PostgreSQL's cost-based optimizer is sufficient for typical workloads and a skilled DBA can tune it to comparable performance. Any workload constrained by SE2's 16-thread execution ceiling was small enough that PostgreSQL usually gains headroom, not loses it.
Ora2Pg 25.x is the primary schema and data conversion tool and produces a per-object difficulty assessment you should run first. AWS DMS 3.5 and later with Schema Conversion suits cloud-targeted moves, and pgLoader 3.6 handles bulk data. These target current PostgreSQL 14 through 18 (18.4 is current as of May 2026). Most residual effort lands in PL/SQL and application SQL dialect.
The license removes up to $35,000 per two-socket server at list, but the larger saving is the recurring 22% support annuity, which over five years exceeds the license itself. Because standalone SE2 discounts top out around 35% to 50%, your current spend is already near list, so the recurring support line is the dominant number in the business case.
Migrating Oracle to PostgreSQL removes the licence and the 22 percent support annuity. The break-even math, what migrates cleanly, and why a credible exit is leverage even if you s
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
