Oracle and SQL Server to Aurora PostgreSQL: Stay, Babelfish, or Convert
Quick summary: A lab renewal only changed the connection string, and a construct was still unconverted. Babelfish speaks TDS 7.1 through 7.4 on port 1433 and does not apply to Oracle. Identifiers longer than 63 characters are rewritten.
Key Takeaways
- Babelfish speaks TDS 7
- 1 through 7
- 4 on port 1433 and does not apply to Oracle
- Identifiers longer than 63 characters are rewritten
- Babelfish for Aurora PostgreSQL accepts SQL Server clients on TDS versions 7
Table of Contents
A renewal plan in the lab only changed the connection string. The diagram drew Babelfish in front of Oracle. Babelfish for Aurora PostgreSQL accepts SQL Server clients on TDS versions 7.1 through 7.4, on port 1433, and still exposes PostgreSQL on port 5432. The Babelfish guide states that it runs T-SQL with differences. PostgreSQL identifiers are 63 characters; Babelfish rewrites longer names (differences). A construct the assessment marked CRITICAL was still unconverted. None of that is a promise that the application is unchanged, and none of it applies to Oracle.
Lab figure, 4 October 2026. Not a customer account. The middle door is SQL Server only. Oracle stays licensed or goes through conversion.
License renewal is the wrong moment to treat the engine as a connection string. The DMS to Aurora playbook owns task setup and cutover. The RDS versus Aurora post and the comparison own the family choice inside an engine you already run. This page owns the fork: stay licensed, put Babelfish in front of a SQL Server subset, or convert to Aurora PostgreSQL and fund what conversion will not rewrite. The product name is DMS Schema Conversion. Older articles on this site still say Schema Conversion Tool. Do not add a third name.
Aurora Limitless is a later scale question. It is not this renewal.
Reproduce this — Copy the renewal worksheet. Fill it from the license exhibit, a Babelfish Compass report for SQL Server, and a DMS Schema Conversion assessment. Do not fill the unsupported counts from memory.
Three forks
Stay on the commercial engine. RDS for Oracle or RDS for SQL Server. Choose this when the database is the product, when the remaining term makes a conversion more expensive than the renewal you can actually see, or when the assessment says the residue is the project. Staying is a decision. It is not a failure to modernize. The trade-off is the license and the engine you keep operating.
Babelfish, SQL Server only. The application keeps talking T-SQL to port 1433. New work can use PostgreSQL on port 5432. AWS tells you to assess first. Babelfish Compass reads DDL and SQL you export and reports what the current Babelfish version does not support. Choose Babelfish when that report’s unsupported list is small enough that you will fund it, and when you accept PostgreSQL underneath. Choose something else when you need the report to say “no code changes.”
Convert to Aurora PostgreSQL. DMS Schema Conversion plus a funded residue, then DMS for the data. The AWS description of action-item severity is the backlog, not a slogan. INFO, LOW, MEDIUM, and HIGH still need a human. CRITICAL means the construct was not converted (the blog’s examples include hierarchyid, full-text search, and CLR). SQL that lives in the application is a fourth bucket the schema report does not contain. Choose convert when those two buckets are staffed before cutover. The playbook tells you how to move the rows. It does not staff the residue.
Oracle does not get the middle fork. There is no Babelfish for Oracle. Oracle stays, or it converts.
We recommend Babelfish over a full SQL Server conversion when Compass says the subset matches and the team will live with the differences. We recommend conversion when the procedure surface is small enough to rewrite and you want one dialect. We recommend staying when the database is the product. The trade-off of Babelfish is a compatibility layer you will still be testing on the next Babelfish version.
What the assessment has to name
Use the worksheet. These are questions, not a score we invented.
| Question | Why it changes the fork |
|---|---|
| Remaining license term, and whether the database is the product | A short term and a database that is the product both argue for staying. A term that outlasts a rewrite you will not fund also argues for staying. |
| Stored procedures, functions, and triggers Compass or Schema Conversion did not accept | That list is the project. A connection-string plan that ignores it will fail after the data has moved. |
| CLR, updatable cursors, contained databases | Unsupported in Babelfish as documented. They are conversion or stay, not “few code changes.” |
| Linked servers | Supported from Babelfish 3.1.0 with the tds_fdw extension. Still a design: install the extension, name the remote, test it. “Unsupported” is the wrong note. “Unplanned” is the failure. |
| Identifiers longer than 63 characters | Babelfish rewrites them. Anything that matches on the original name breaks. |
| SQL in the application, ORMs, and reports | Absent from a schema-only assessment. Staff it before cutover or the weekend only proves that rows moved. |
| PostgreSQL and T-SQL in the same application | The compatibility guide warns that mixing the two in one application context can interfere. Read that before you promise both ports to the same code. |
DMS itself does not create every schema object. Secondary indexes and some constraints are a known gap, which is why heterogeneous migrations use DMS Schema Conversion rather than the data task alone. Cutover mechanics stay on the playbook.
Where this fails
Lab figure, 4 October 2026. Not a customer account. The check is the assessment before cutover: CRITICAL means the construct was not converted.
The program treats a CRITICAL line as a warning and changes the connection string. DMS full load completes. The feature that called the unconverted procedure, or the CLR assembly, fails in production. Detection is the assessment, before cutover, not the error budget after it. The fix is to staff CRITICAL items and application SQL, or to stay on the commercial engine. It is not a second full load.
The SQL Server variant is a Babelfish cutover with no Compass report. The differences table is long on purpose. @@version format, checksum algorithm, and identifier length are enough to break a client that parsed SQL Server’s strings. Compass exists so that list is yours, not a blog’s sample.
What to Do This Week
- Separate Oracle from SQL Server. They do not share a middle option.
- Record the license end date and whether the database is the product.
- For SQL Server, run Babelfish Compass on exported DDL and SQL. Do not choose Babelfish from a slide.
- For a conversion, read the Schema Conversion assessment as a backlog: converted, converted-with-warnings, not converted, and SQL that is not in the database.
- Send cutover design to the DMS playbook. Send the fork, if you want it reviewed, to RDS consulting.
What This Post Doesn’t Cover
MySQL’s choice between RDS MySQL, Aurora MySQL, and Aurora PostgreSQL is a different article. Limitless shard keys are a different article. The list of objects Schema Conversion will not rewrite, beyond the severity rule above, is the residue article. This page does not include task settings, LOB lag, or a cutover checklist. It does not estimate license savings. Confirm Babelfish’s unsupported list against the current Aurora guide before you freeze a design. The list moves with the engine version.
Frequently asked questions
Can Babelfish move Oracle to Aurora PostgreSQL?
No. Babelfish is a SQL Server compatibility endpoint on Aurora PostgreSQL. Oracle stays on RDS for Oracle or goes through a conversion to Aurora PostgreSQL. Treating both engines as one connection-string project is the mistake this decision exists to stop.
When should we not choose Babelfish?
Do not choose it when Babelfish Compass reports an unsupported surface you will not fund, when the application also issues PostgreSQL against the same objects without reading the interoperability guidance, or when you need a feature the unsupported list still names. CLR routines, updatable cursors, and contained databases are unsupported. Linked servers are not a blanket no: Babelfish 3.1.0 and later can use the tds_fdw extension, and that still has to be designed and tested.
What could go wrong if DMS moves the data and we only change the connection string?
DMS moves rows. DMS Schema Conversion classifies objects. A CRITICAL item is a construct that was not converted. SQL that lives in the application never appears in the schema report. The cutover can succeed and the feature can still fail. Staff the unconverted objects and the application SQL before you pick a weekend.
When should we stay on RDS for Oracle or RDS for SQL Server?
Stay when the database is the product, when the remaining license term is the cheaper path than the residue, or when the assessment says the unsupported or unconverted surface is the project. A renewal is not automatically a migration.
Where is the cutover runbook?
Task setup, LOB handling, and the Aurora cutover checklist stay on the DMS to Aurora playbook. This page is the engine and license fork. It links that playbook. It does not replace it.
Is Aurora Limitless part of this decision?
No. Limitless is horizontal SQL after you already run Aurora PostgreSQL and a single writer is the bottleneck. Link it only to keep it out of the license renewal.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
