AI-assisted Oracle-to-PostgreSQL schema conversion in Visual Studio Code

By Aditya Duvuri, Anil Dogra, Pranay Lohia, AI Omar Rajawat, Gautam Juneja, Vikas Nimmagadda

There’s a growing trend towards moving database workloads from Oracle to Azure Database for PostgreSQL. One of the most daunting challenges in this process has traditionally been schema conversion, which often requires deep technical expertise in both databases and can extend migration timelines significantly. However, recent advancements in AI-assisted schema conversion are transforming this task, making it quicker, more accessible, and cost-effective. In this article, we’ll explore what these changes mean for teams transitioning to the Azure Database for PostgreSQL flexible server.

Schema conversion from Oracle to PostgreSQL highlights the complexities involved in translating various schema and code elements. Teams must carefully map packages, procedures, triggers, custom types, and long-standing dependencies into definitions that are compatible with PostgreSQL, all while preserving vital relationships within the schema.

Since its general availability in May 2026, this feature has been seamlessly integrated into the PostgreSQL extension for Visual Studio Code, developed by Microsoft. It empowers teams to convert Oracle schema and code elements — including tables, views, constraints, packages, procedures, functions, and triggers — into definitions suitable for Azure Database for PostgreSQL flexible server without the need for a separate conversion tool or a complicated workflow.

This integration offers a streamlined experience covering schema discovery, conversion, validation, and review within a single project. Teams can connect to Oracle, select the schemas they wish to migrate, and set up a Microsoft Foundry connection all within the same project environment. The extension handles Oracle-specific constructs, compiles and syntax-checks the converted DDL into scratch schemas on Azure Database for PostgreSQL flexible server, and highlights unresolved items as review tasks which teams can address alongside the GitHub Copilot agent mode.

While traditional conversion tools can provide an initial useful output, they often fall short in addressing ongoing practical concerns: What has converted successfully? What aspects need more attention? Which Oracle elements demand a specific PostgreSQL design decision? Which items should teams prioritise for review?

We designed our schema conversion process to tackle those questions directly. The aim is to enable teams to make consistent progress while ensuring that all work remains visible and can be reviewed easily.

Our approach guides teams through a comprehensive schema conversion project instead of handing them a set of separate scripts. It examines the chosen Oracle schemas and converts both the relational model and the associated code: tables, indexes, sequences, constraints, views, and even the challenging PL/SQL elements. Packages and package bodies, standalone procedures, and triggers are transformed into corresponding PostgreSQL functions and procedures.

During this mapping process, Oracle-specific elements are appropriately translated into PostgreSQL equivalents rather than ignored or dropped. For instance, REF CURSOR and SYS_REFCURSOR will convert to PostgreSQL refcursor; CLOB and BLOB columns change to text and bytea, respectively; while NUMBER and VARCHAR2 are translated with precision and length adjustments. Functions like ADD_MONTHS and LAST_DAY are resolved using the orafce extension, which our system detects and flags prior to deployment. Every converted definition is compiled against scratch schemas on Azure Database for PostgreSQL flexible server, ensuring that the final deployment script consists of a well-organised, dependency-ordered set of PostgreSQL SQL artifacts already confirmed to build correctly.

Any items that still need human assessment are highlighted as review tasks. Teams can compare the source and converted definitions side by side, tackle the outstanding tasks, and seek guidance from GitHub Copilot agent mode, effectively blending automation with human oversight.

At the core of our conversion engine is a straightforward principle: the language model operates as a single, defined stage; it doesn’t solely dictate the start or end of the process. A structured approach determines what the model can view and produce.

• Consistent input. The extraction process reads the Oracle DDL and metadata, while a dependency-graph decomposition breaks this down into manageable, ordered segments, ensuring every object is converted in context.
• Structured conversion. Our tiered model translates each segment using a Microsoft Foundry connection, processing even large PL/SQL packages member by member to ensure nothing is assumed as a single entity.
• Thorough output. Converted objects undergo rigorous review, compiling and validating against scratch schemas on Azure Database for PostgreSQL flexible server before being assembled into a dependency-ordered deployment package. Any unresolved items appear as review tasks, complete with an audit trail for each object.

We maintain a cycle of continuous improvement: our engineering team oversees a versioned regression suite of conversion patterns, enabling us to track regressions as the process advances.

This method has been tested on actual enterprise estates. In our representative production runs involving over 60,000 schema objects, we achieved an impressive overall conversion rate of approximately 98%, with some schemas converting at a flawless 100%. The most challenging areas, such as PL/SQL package members, now compile at 96% across over 20,000 members, due to targeted coverage and a robust compile process.

Conversion outcomes and review statuses are treated as separate metrics. Objects that convert and compile without issues can be deployed safely; others go into a prioritised review queue, ensuring they aren’t just accepted without scrutiny. In a recent single-schema run, no object faced an irreversible conversion failure, and even well-generated objects can require careful PostgreSQL design decisions. This is the intended workflow: automation handles the volume, while review tasks keep any remaining decisions clear, organised, and accountable.

We assure quality through practical testing. The SchemaBench evaluation framework deploys each converted schema to a live PostgreSQL database where it tests real-world behaviour — checking whether constraints are active and if the objects resolve as necessary — rather than just comparing DDL text. It assesses seven aspects: semantic fidelity, structure, constraints, completeness, performance, target idioms, and maintainability, all subject to rigorous standards. In one e-commerce benchmark, the top model achieved a score of 96.1 overall, achieving 100% semantic fidelity and nearly 98% pass rate on behavioral tests. Every challenge faced during migration becomes a permanent regression test for the next iteration.

Discover more: Oracle to Azure Database for PostgreSQL schema conversion overview