The conversion pipeline.

The pipeline runs in seven stages. Each stage emits an artifact that the next stage consumes. Stages are independently runnable, independently auditable, and independently restartable.

1. 1. Catalog extraction.

   The extractor walks every Oracle data-dictionary view and serializes every catalog object into a portable, inspectable format. Tables, indexes, sequences, types, packages, triggers, views, materialized views, synonyms, grants, and database links land on disk before a single statement runs.

2. 2. Parse-tree construction.

   Every Oracle SQL and PL/SQL artifact is parsed into a real abstract syntax tree. Qualified identifiers, nested blocks, cursors, exceptions, BULK COLLECT, FORALL, and compound triggers all land as structured nodes, not text fragments.

3. 3. Rule application.

   Two hundred-plus Oracle-to-PostgreSQL translation rules apply against the tree. Each rule is a named, versioned, test-backed transformation. Every node carries a rule reference back to the audit log.

4. 4. Code emission.

   The transformed tree is rendered back to PostgreSQL source. Formatting is deterministic. Two runs against the same input produce byte-identical output.

5. 5. Dependency graph.

   A graph of inter-object dependencies is built from the parse trees. The orchestrator uses it to choose deployment order, identify retryable failures, and short-circuit cascades that would otherwise generate thousands of noise errors.

6. 6. Deployment.

   The 14-phase orchestrator runs against a real PostgreSQL target in dependency order. Failures retry across passes as dependencies become available. Convergence is automatic.

7. 7. Validation.

   Row counts, checksums, and sample-row equivalence are validated against the source. Out-of-scope features are reported with explicit rationale. The migration is signed off or it is not done.

Parse trees, not regex.

Regex-based converters work for straightforward DDL. They fail on the long tail of PL/SQL: nested blocks, qualified identifiers, package state, %TYPE and %ROWTYPE references, compound triggers, BULK COLLECT into record types, FORALL with SAVE EXCEPTIONS, and cursor-driven control flow. Trekport parses every artifact into a real syntax tree and transforms the tree. The difference is not theoretical. It is the difference between a migration that finishes and a migration that turns into a services contract.

The 14-phase deployer.

Each phase runs in dependency order. Each phase is retryable. Each phase emits a typed report. Failures route through the classifier before they hit a human.

1. 01

   Pre-flight

   Validate connectivity, version skew, and target capacity.

2. 02

   Extensions

   Install the compatibility layer before any schema lands.

3. 03

   Schemas and roles

   Materialize the namespace and identity surface.

4. 04

   Types

   Domain types, composite types, and collection types first.

5. 05

   Sequences

   Deploy before tables so identity columns wire correctly.

6. 06

   Tables

   Without foreign keys. Constraints land after data.

7. 07

   Indexes

   Including primary keys and unique constraints.

8. 08

   Procedures and functions

   Including overloads, defaults, and OUT parameters.

9. 09

   Packages

   Body and spec lowered to schema-plus-functions.

10. 10

    Triggers

    Including compound triggers with FOR EACH ROW and statement-level fires.

11. 11

    Views and materialized views

    Dependency-ordered, with refresh strategies preserved.

12. 12

    Synonyms

    Public synonyms reconciled to PostgreSQL search paths.

13. 13

    Grants and ACL

    Object grants, column grants, and role memberships.

14. 14

    Foreign keys and validation

    Constraints applied last. Row counts, checksums, and sample-row equivalence checked.

The classifier.

Every deployment failure routes through a four-bucket classifier before it reaches a human. Each bucket carries a concrete fix path. Closing the loop is a product feature, not a release note.

The compatibility layer.

PostgreSQL is a complete database, but it is not Oracle. The compatibility layer closes the gap with battle-tested community extensions. Trekport-authored extensions handle anything the community has not covered.

Validation.

Validation is part of the pipeline, not an afterthought. Row counts, checksums, and sample-row equivalence run against the source after data load. Smoke queries exercise representative read paths. The validation report is the artifact that goes to change-management review.

Performance characteristics.

Trekport extracts and converts at a sustained rate of up to 100,000 catalog objects per hour on a single workstation. Catalog extraction is parallel by schema. Conversion is parallel by object. Deployment is parallel where the dependency graph allows. Memory profile is bounded by configurable batch size.