When AWS SCT is not enough.
AWS Schema Conversion Tool is a capable free tool for schema-first migrations onto Amazon RDS and Aurora. The gap shows up on PL/SQL packages, compound triggers, bulk-bind constructs, and dependency-ordered deployment. Here is how Trekport closes it in independent testing.
The headline difference.
AWS SCT publishes an upper bound on automated conversion. The remaining work is the difficult subset: PL/SQL packages with circular references, compound triggers, BULK COLLECT and FORALL, autonomous transactions, and the dependency-ordered deployment. For an enterprise estate, that subset translates into multiple engineer-quarters of manual cleanup.
AWS SCT
- ·Pattern-rule conversion with assistance
- ·Strong on schema-first migrations onto RDS and Aurora
- ·PL/pgSQL output flags difficult constructs for manual implementation
- ·Catalog-order export with operator-scripted dependency reconciliation
- ·Requires an AWS account, targets RDS or Aurora
- ·Free, with separate hourly cost for AWS Database Migration Service compute
Trekport
- ·AST-based conversion (parse tree, not pattern matching)
- ·Classifier-routed diagnostics on every failure
- ·Set-based translation for BULK COLLECT and FORALL with package state preserved
- ·14-phase dependency-ordered deployment with iterative retry
- ·Runs on your machine. Targets any PostgreSQL 14 through 18
- ·Commercial license. Launch pricing announced soon
Capability comparison.
| Capability | Trekport | AWS SCT |
|---|---|---|
| Conversion approach | AST-based | Pattern and assistance |
| PL/SQL packages | Engine-driven | Partial. Manual cleanup expected |
| Compound triggers | Supported | Partial |
| BULK COLLECT | Set-based translation | Flagged for manual implementation |
| FORALL | Array-bound bulk DML | Flagged for manual implementation |
| Autonomous transactions | Supported through extensions or refactor | Manual rewrite |
| Dependency-ordered deployment | 14-phase pipeline | Operator-scripted ordering |
| Diagnostics | Four-bucket classifier | Action-item list |
| Validation reports | HTML, PDF, JSON | Assessment report |
| Runs without vendor account | Yes | No. AWS account required |
| Target compatibility | PostgreSQL 14 through 18, multi-cloud | RDS and Aurora primary |
The bulk-bind difference.
Bulk-bind constructs are where the engineering difference shows up clearly. The Oracle original below executes correctly. AWS guidance acknowledges that automated tooling leaves these constructs to manual implementation. Trekport translates the construct to set-based PostgreSQL that executes the original logic.
-- Oracle original (executes correctly)
DECLARE
TYPE id_list IS TABLE OF NUMBER;
ids id_list;
BEGIN
SELECT id BULK COLLECT INTO ids FROM employees WHERE active = 'Y';
FORALL i IN 1..ids.COUNT
UPDATE employees SET reviewed_at = SYSDATE WHERE id = ids(i);
END;
-- Trekport output (set-based, faster than the original)
DO $$
DECLARE
ids INTEGER[];
BEGIN
SELECT ARRAY_AGG(id) INTO ids FROM employees WHERE active = 'Y';
UPDATE employees SET reviewed_at = NOW() WHERE id = ANY(ids);
END $$;The Trekport version is shorter, runs without a per-row PL/SQL context switch, and most importantly executes the original logic. Bulk-bind handling is the failure mode that has historically cost Oracle migration projects months of debugging.
When AWS SCT is still the right call.
For schema-first migrations of tables, views, indexes, and sequences onto RDS or Aurora, AWS SCT is a capable free tool. The trade-offs begin to matter at scale: PL/SQL-heavy estates, dependency-ordered deployment, regulated environments, and multi-cloud or on-premises targets.
FAQ
Where does AWS SCT typically need manual cleanup?
PL/SQL constructs that depend on Oracle semantics with no direct PostgreSQL equivalent: BULK COLLECT, FORALL, compound triggers, package-level state, autonomous transactions, and dependency-ordered grants. AWS engineering guidance acknowledges that SCT translates several of these constructs into PL/pgSQL shells that compile cleanly but require manual implementation. Trekport handles these constructs through the engine and surfaces classifier-routed diagnostics for anything that lands out of scope.
Can I use Trekport without an AWS account?
Yes. Trekport runs entirely on your machine. It connects directly to your Oracle source and PostgreSQL target. No AWS account, no region selection, no replication-instance provisioning. Suitable for on-premises, hybrid, and air-gapped deployments where AWS is not the target.
Does Trekport convert PL/SQL packages?
Yes. The conversion engine lowers Oracle PACKAGE SPEC and BODY to schema-plus-functions with package state preserved. Overloaded signatures, circular package references, and dependency-ordered grants are handled by the engine, not by the operator. The 14-phase deployer resolves the dependency closure automatically.
How does Trekport handle BULK COLLECT and FORALL?
Trekport translates BULK COLLECT into set-based PostgreSQL constructs using array aggregation and unnest patterns. FORALL becomes a single UPDATE or INSERT against an array-bound input. The translated PostgreSQL eliminates the per-row PL/SQL context switch and is typically faster than the Oracle original. The translated output executes the original logic. It is not a stub.
What if my target is RDS for PostgreSQL or Aurora?
Trekport targets any PostgreSQL 14 through 18, including AWS RDS for PostgreSQL, Amazon Aurora PostgreSQL-Compatible, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, Google AlloyDB, and self-managed PostgreSQL. The output is vanilla PostgreSQL plus the orafce extension, so it is portable across providers.
Try Trekport against your Oracle estate.
Reserve priority access to run Trekport against your own catalog. Evaluation terms and onboarding from a Trekport engineer included when your wave opens.