Oracle to Azure Database for PostgreSQL flexible server schema conversion limitations

This article summarizes the known limitations, unsupported objects, and migration considerations when you use the Oracle to Azure Database for PostgreSQL schema conversion feature in Visual Studio Code.

Platform support limitations

  • ARM64: Not supported on Windows or Linux.

Schema conversion requires PostgreSQL 15 or later. For the supported operating systems, including macOS 13 or later, see the tutorial prerequisites.

Unsupported and partially supported objects

The following sections describe unsupported objects, partial conversion, and features that need manual review. An individual object's outcome depends on its source definition, dependencies, and target prerequisites.

Discovery, extraction, conversion, and deployment describe different stages. An object can be discovered but excluded from extraction, or extracted but not converted. Review Discovery results for source scope, the HTML conversion report and Conversion Object Explorer for conversion results and notes, and Setup Experience reports for deployment results.

Oracle system and built-in schemas aren't extracted or converted. This includes schemas such as SYS, SYSTEM, XDB, MDSYS, CTXSYS, and WMSYS.

Important

A Converted result doesn't by itself establish compilation success, a complete implementation, deployment inclusion, or equivalent runtime behavior. Compilation checks syntax and structure, not data or application behavior. Review both Converted and Not converted objects, and complete separate runtime testing before production use.

Placeholder output

When the tool can't fully convert an object, it might emit best-effort or placeholder DDL. Some objects have no usable PostgreSQL definition.

A placeholder doesn't implement the original business logic. For example, a generated routine whose body raises an error can still appear as Converted. Inspect the generated definition and any conversion notes rather than relying on the status alone.

Objects that depend on a placeholder can require manual changes or be omitted from the generated deployment script. Review these dependencies in Conversion Object Explorer before deployment.

Cases that can require manual completion include:

  • Autonomous transactions. Conversion of routines that use PRAGMA AUTONOMOUS_TRANSACTION can depend on dblink. Missing required extensions or unsupported transaction logic can prevent a complete conversion.
  • Unresolved references. Missing or unresolved dependencies can prevent complete conversion or compilation.
  • Transaction control statements. Constructs such as ROLLBACK TO SAVEPOINT don't always convert cleanly.
  • Wrapped PL/SQL. The source body isn't available for conversion. For more information, see Wrapped PL/SQL.

Programmable objects

Object type Limitation What to do
Package body Converted package definitions don't establish equivalent state initialization or persistence across calls. Test shared state across calls, transactions, and sessions against your application's expectations.
Routine that uses PRAGMA AUTONOMOUS_TRANSACTION Conversion can use a separate connection through dblink. The generated connection handling and transaction logic need review. Install required extensions before conversion. Test connection and session context, data visibility, commits, rollbacks, and error handling.
Trigger (system event) Compilation of a generated trigger doesn't establish equivalent Oracle database or session-event handling. Review LOGON, LOGOFF, STARTUP, SHUTDOWN, and SERVERERROR triggers explicitly. Validate the target event, scope, and permissions, and reimplement logic that the target doesn't support.
Trigger (cross-edition) A mapping to an ordinary PostgreSQL trigger needs review for loss of Oracle edition scoping. Convert a single edition, verify when the target trigger fires, and handle version rollout in your release process.
Type body Type bodies can be extracted, but extraction doesn't guarantee a complete PostgreSQL implementation of their methods. Review the generated definitions for type methods and their dependencies. Implement any missing logic manually.
Java source, Java stored procedure, and Java class Not extracted. Azure Database for PostgreSQL flexible server can't run Java in the database. Rewrite the logic in PL/pgSQL or move it to the application layer.
External C library (CREATE LIBRARY) Not extracted. Rewrite the logic in PL/pgSQL or move it to the application layer.
Wrapped PL/SQL The body can't be read. Generated output can contain placeholders rather than the original implementation. For more information, see Wrapped PL/SQL. Obtain the original unwrapped source before starting conversion, or implement the missing PostgreSQL logic manually.

Wrapped PL/SQL

The tool can't read the implementation of PL/SQL units stored in wrapped (obfuscated) form by using the Oracle wrap utility or DBMS_DDL.WRAP. It might use available metadata to generate a placeholder, such as a routine that raises an error when called. This output doesn't reconstruct the original business logic.

Review wrapped units in Conversion Object Explorer even if their status is Converted. Inspect the generated definitions, conversion notes, and dependencies to identify missing implementations. A placeholder doesn't guarantee that dependent objects convert or deploy.

Obtain the original unwrapped source before starting conversion. If conversion has already completed, implement and validate the missing PostgreSQL logic manually. Rerunning a completed conversion isn't supported.

Data and storage objects

Object type Limitation What to do
User-defined operator (CREATE OPERATOR) Conversion isn't guaranteed and can produce placeholder output. Review the generated operator and test it.
Index (bitmap, bitmap join, global partitioned, or domain) Not extracted. PostgreSQL doesn't use Oracle bitmap or domain indexes. Review application dependencies on index-specific features, choose appropriate target indexes, and test query behavior and performance.
Materialized view log (MLOG$) Not extracted. Define and test the target materialized-view refresh strategy, including refresh schedules and data-freshness requirements.
External table Not extracted. Azure Database for PostgreSQL flexible server has no server filesystem access, so file_fdw isn't available. Load the file into a table with a client-side \copy or COPY ... FROM STDIN, with the azure_storage extension, or through your application.
Advanced Queuing (AQ) table Not extracted. Oracle Advanced Queuing carries application logic. Redesign it with an application queue, a PostgreSQL extension, or an Azure messaging service.
Blockchain table Not extracted. Reimplement the integrity requirement in the application layer.
Cluster and hash cluster Not extracted. Recreate as a plain or partitioned table.
Directory object (CREATE DIRECTORY) Not extracted. Handle file access in the application layer.
User-defined index type (CREATE INDEXTYPE) Not extracted. Recreate the access method with a PostgreSQL extension index where one exists.
Database link Not converted. For more information, see Database links. Recreate with a foreign data wrapper.
Synonym Some synonyms, including those that reference packages, procedures, or sequences, might not convert. Review target mappings and update dependent SQL to reference the appropriate PostgreSQL objects.
Application context (CREATE CONTEXT, DBMS_SESSION.SET_CONTEXT) Not extracted. Map the context to PostgreSQL session settings, and read them with current_setting().
Analytic view, attribute dimension, hierarchy, OLAP dimension, data mining model, and materialized zone map Not extracted. These have no PostgreSQL target. Rebuild the required output as views or functions, or drop them.
LOB storage clause, registered XML schema (DBMS_XMLSCHEMA.REGISTERSCHEMA), and XML schema-bound index Not extracted. Remodel the storage or validation requirement on the target.
Resource Manager plan and consumer group, SQL profile, SQL plan baseline, edition, SQL Translation profile, Information Lifecycle Management policy, lockdown profile, and Workspace Manager object Not extracted. These are Oracle instance, optimizer, or lifecycle artifacts that are out of scope. Recreate them at the application or infrastructure layer, or drop them on Azure Database for PostgreSQL.

The tool doesn't automatically convert private and public database links (CREATE DATABASE LINK, CREATE PUBLIC DATABASE LINK). Database links store credentials and remote endpoint information that don't translate directly to PostgreSQL.

Recreate these links on the target by using a PostgreSQL foreign data wrapper such as postgres_fdw or oracle_fdw, or refactor to application-level connections. Search your Oracle source for @link references so that you find every dependency, including references inside synonyms and views.

Security and identity objects

Automated conversion of security and identity objects isn't supported. Plan and validate users, roles, privileges, and data-protection policies separately from converted schema DDL. Use your Oracle source inventory to identify required access controls. Discovery listings or extracted metadata don't establish conversion support or confirm that access controls are configured on the target.

Object type Limitation What to do
User Automated conversion isn't supported. Provision logins separately on Azure. Recreate each user as a PostgreSQL role, and validate the resulting access before you go live.
Role Automated conversion isn't supported. Recreate each role on the target.
System privilege Automated conversion isn't supported. Map the required access to PostgreSQL privileges, then apply the appropriate GRANT statements.
Role membership Automated conversion isn't supported. Recreate as GRANT <role> TO <role> statements.
Object privilege and grant Source grant metadata doesn't configure equivalent target permissions. Recreate grants from your source inventory, then validate them.
Row-level security and Virtual Private Database (DBMS_RLS) Not converted. Recreate the policies as PostgreSQL row-level security policies.
Oracle Label Security Not converted. Redesign the data-access boundaries on the target.
Data redaction (DBMS_REDACT) Not converted. Reapply masking on the target, in the application layer or with a PostgreSQL equivalent.
Profile, password policy, and unified or fine-grained audit policy (DBMS_FGA, AUDIT POLICY) Automated conversion isn't supported. Configure the equivalent Azure server parameters and auditing, and manage them as infrastructure as code.

Important

Missing row-level security, Virtual Private Database, Oracle Label Security, or data redaction protections can expose rows or values that Oracle filtered or masked. Implement equivalent protections and verify effective access before you route production traffic to the target.

Scheduler objects

Automated conversion of Oracle scheduler objects isn't supported. Plan scheduling and orchestration separately. An object appearing in Discovery doesn't establish conversion support.

Object type Limitation What to do
DBMS_SCHEDULER job and schedule Automated conversion isn't supported. Recreate the schedule on the target with pg_cron, or use an external scheduler such as Azure Logic Apps or Azure Functions.
Legacy DBMS_JOB job Automated conversion isn't supported. Recreate the schedule with pg_cron or an application scheduler.
Program, chain, credential, file watcher, job class, group, window, and event-based job Automated conversion isn't supported. Rebuild the orchestration in an external scheduler.

Feature-level gaps

The following items are Oracle features rather than object types. They can require changes beyond creating valid PostgreSQL DDL. Review your source inventory as well as the converted definitions, because feature-level differences might not appear as separate objects in the conversion results.

Feature Limitation What to do
Hybrid partitioned table (Oracle 19.3 and later) Converts as an ordinary table, and the external partitions are lost. Identify hybrid partitioned tables in the source, and load the external data separately.
Editioning view and cross-edition trigger A PostgreSQL view or trigger definition alone doesn't establish equivalent edition-based behavior. Convert one edition, then validate object visibility and trigger behavior during version rollout.
Immutable table (Oracle 19.11 and later) Not detected, and there's no PostgreSQL equivalent. Enforce the requirement in the application layer or with triggers.
Flashback Data Archive Temporal history isn't modeled. Use a history table pattern or a temporal extension on the target.
Flashback query (AS OF TIMESTAMP, AS OF SCN) Not converted. Rewrite queries that read historical versions of a row.
Oracle Sharding Not modeled, and there's no single-database PostgreSQL equivalent. Redesign the distribution strategy.
BFILE and SecureFile LOB specifics External file contents and LOB storage behavior require separate migration planning. Review external file references and dependencies on Oracle-specific LOB features. Plan and test the target storage and access pattern.

Even when identity columns, virtual and generated columns, invisible columns, and global temporary tables convert, validate their definitions and behavior with your application. Check value generation, column visibility, temporary-data lifetime, and transaction behavior. Private temporary tables exist only at runtime, so they don't appear in the source inventory.

Operational boundaries

Keep these boundaries in mind when planning the migration:

  • Schema conversion doesn't migrate row data. Plan data migration and data validation separately from schema conversion.
  • Conversion reruns aren't supported. Review and correct the generated PostgreSQL definitions through Conversion Object Explorer. Compile edited definitions manually, and verify that deployment SQL includes the corrections you intend to deploy.
  • Scratch schemas are recreated. Existing scratch schemas that correspond to the selected Oracle schemas are dropped with DROP SCHEMA ... CASCADE and recreated. Use an empty or dedicated, unused scratch database with no objects or data you need to preserve. See Prepare the scratch database.
  • Deployment is a separate operation. Generating setup files doesn't execute them against your Azure Database for PostgreSQL destination server. Review the instructions, run the generated scripts, and inspect deployment and object-verification results as described in the Setup Experience.

Get help

When you encounter limitations:

  1. Review Conversion Object Explorer for object definitions and conversion notes. Use Ask to understand an object's conversion or Fix for Copilot-assisted changes to its PostgreSQL file.
  2. Consult PostgreSQL documentation for alternative implementations.
  3. Review best practices for Oracle to Azure Database for PostgreSQL migration patterns.
  4. Test in a nonproduction environment before deploying to production.

Related content

  • Last updated on