{
  "id": 16872593,
  "title": "Oracle to PostgreSQL Migration: The Residue Report I'd Price From",
  "url": "https://urgent.news/2026/10/28/oracle-to-postgresql-migration-the-residue-report-id-price-from",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-28T08:39:07.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/abyzgenic/oracle-to-postgresql-migration-the-residue-report-id-price-from-525p"
  },
  "original_language": "en",
  "account": "Before choosing an Oracle to PostgreSQL migration tool, scrutinize the list of items it cannot convert. This list serves as your quote. The actual conversion of DDL is relatively inexpensive. Upon reading the pgrecon announcement on the PostgreSQL news page twice, the benchmark table raised suspicion. It was investigated to determine if the suspicion was justified. Testing pgrecon against a real Oracle environment was not performed; this report is based on the project's claims and the writer's prior migration experiences, not a test report. When quoting fixed-price database migrations or handling such projects, this aspect should be the first point of consideration. The schema script is the cheapest part of every Oracle migration pitch. Demos typically show tables moving from one side to the other. However, the true expense lies elsewhere: PL/SQL packages that maintain state across calls, triggers that write audit rows in their own transaction, database-scheduled jobs, and application code that subtly relies on Oracle's handling of empty strings. The last point is particularly noteworthy, as it can cause significant issues for those who believe the migration is complete. Oracle treats an empty string as NULL, while PostgreSQL does not. A column that has always been optional in practice, with the application sending an empty string, behaves differently on Oracle and PostgreSQL. No DDL converter can rectify this. The critical question for any tool is not how much it converts but how transparently it informs you about what it leaves behind. Pgrecon outlines three stages: a DBA runs a read-only SQL*Plus script, which is then loaded into a local SQLite inventory without connecting to either database. A rule engine consisting of 80 rules processes the inventory, and a converter generates PostgreSQL DDL for what it can validate as equivalent. Two noteworthy design choices were observed. First, the offline dump is preferred over other methods. Many Oracle estates belong to companies where contractors won't receive a connection string until the first week. A short, auditable script that the DBA can run line by line using a read-only account is a more feasible option. The script's shortness is essential, as security reviewers will focus on it. The second noteworthy aspect is the residue report. Items that the converter cannot carry faithfully are presented as named lines rather than emitted DDL. Examples include a view using JSON_TABLE, a trigger running an autonomous transaction, a compound trigger, and an external file locator column without a direct equivalent. Each example represents a different type of work, ranging from an afternoon for the view to a design decision for the autonomous transaction and a conversation with the file owner for the external file locator. A comprehensive list with attached reasons is necessary to turn the vague statement \"it took about six months\" into a defendable number. What the conversions actually look like can be illustrated using the classic Oracle top-N pattern: SELECT * FROM ( SELECT employee_id, last_name FROM employees ORDER BY salary DESC ) WHERE ROWNUM = 10; in Oracle becomes SELECT employee_id, last_name FROM employees ORDER BY salary DESC LIMIT 10; in PostgreSQL. The announcement states that the converter now converts ROWNUM top-N bounds to LIMIT. However, one must prove that the tool can handle all scenarios. For instance, if someone wrote the lazy version without a subquery, where ROWNUM = 10 ORDER BY salary DESC, Oracle applies the row limit before sorting and returns ten arbitrary rows. A mechanical conversion to LIMIT could silently change the behavior to return the real top ten, a change that should be signed off on before proceeding. Hierarchies and other complex scenarios, such as CONNECT BY and ORDER SIBLINGS BY, also require thorough testing before trusting any summary. Additionally, both extraction tiers in pgrecon capture character versus byte length semantics, meaning VARCHAR2(30 CHAR) in Oracle maps to varchar(30) in PostgreSQL. While this may seem harmless when moving data in one direction, it can cause issues when moving data back later, particularly if Oracle remains a fallback option during the cutover process. Analyzing the benchmark table presented by the vendor added suspicion to the writer's mind.",
  "summary": "Short version for the impatient: before you pick an Oracle to PostgreSQL migration tool, ask it for the list of things it refuses to convert. That list is your quote. The converted DDL is the cheap part. I read the pgrecon announcement on the PostgreSQL news page twice this week. The first read was for the feature list. The second was because the benchmark table made me suspicious, and I wanted…",
  "key_points": [
    "Oracle to PostgreSQL migration tool's residue report reveals items it cannot convert faithfully.",
    "Empty string handling differs between Oracle and PostgreSQL, posing significant challenges.",
    "pgrecon outlines three stages: rule engine processing inventory and generating PostgreSQL DDL."
  ],
  "editors_take": "Prioritizing a tool's ability to report unconvertible logic over its successful DDL translation shifts the focus from simple schema movement to the complex manual labor required for a functional migration.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}