SQL Server to Aurora PostgreSQL Migration: Babelfish vs Full Conversion

The short answer

There are two ways to move SQL Server to Aurora PostgreSQL. Babelfish for Aurora PostgreSQL adds a second endpoint that speaks SQL Server's TDS protocol and runs T-SQL, so applications keep their SQL Server drivers and much of their code. A full conversion rewrites the schema and T-SQL into native PostgreSQL, with DMS Schema Conversion or AWS SCT doing the first pass and AWS DMS moving the data.

Choose Babelfish when the application is hard to change: third-party software, code with no active team, or a hard deadline to leave SQL Server. Choose a full conversion when you own the code and want the database to stay ordinary PostgreSQL that any PostgreSQL platform can run. Many teams do both in sequence: Babelfish to get off SQL Server, then native PostgreSQL over time.

Babelfish and full conversion side by side

What Babelfish is

Babelfish extends an Aurora PostgreSQL cluster so it accepts connections from SQL Server clients. T-SQL clients connect on port 1433 and PostgreSQL clients on port 5432, against the same data. AWS says Babelfish runs T-SQL "with some differences" and keeps a page of them, and the feature has gained functions in each release since it first shipped with Aurora PostgreSQL 13.4. It is available on all supported Aurora PostgreSQL versions from 13 upwards.

Babelfish is also an open-source project, licensed under Apache 2.0 or the PostgreSQL licence. Its four extensions depend on patches to community PostgreSQL, which the project keeps in a separate repository. You can run it outside AWS, but you then build and operate that modified PostgreSQL yourself.

What Babelfish does not support

AWS lists these limits for Babelfish on Aurora:

• Aurora features: IAM database authentication, Database Activity Streams, the RDS Data API, RDS Proxy, SCRAM authentication, the query editor, zero-ETL integrations and querying Iceberg or Parquet data.
• Distributed transactions: connection attributes for Microsoft Distributed Transaction Coordinator, including XA calls from the SQL Server JDBC driver.
• Some PostgreSQL extensions, among them citext, hstore, ltree, pgcrypto and logical replication with pglogical.
• The jTDS driver. Use Microsoft's drivers.

The open-source project's own list of unsupported SQL Server features includes CLR routines and assembly modules, availability groups, the BACKUP statement and BEGIN DISTRIBUTED TRANSACTION. Run Babelfish Compass, the project's open-source assessment tool, against your schema scripts and captured queries to see which of your objects are affected. Its latest release is from September 2026.

AWS also warns about mixing access paths. If the same application context uses both the T-SQL endpoint and native PostgreSQL features, schema names, identifiers, permissions, transaction semantics and collations can interfere with each other, and behaviour can change between Babelfish versions. Pick one primary path per application.

Path A: migrate to Babelfish step by step

1. Choose the migration mode. Single-database mode keeps SQL Server schema names unchanged when seen from PostgreSQL. Multiple-database mode, the default from Aurora PostgreSQL 16, supports several databases from one SQL Server instance and shows their schemas from PostgreSQL as dbname_schemaname. AWS says the mode must not change after the cluster is created, or you may lose access to existing objects.
2. Create the cluster with Babelfish on. Set rds.babelfish_status in a cluster parameter group, then create the cluster with it. Check the default collation, which is sql_latin1_general_cp1_ci_as with locale en-US, against your source.
3. Script the source. Use the SQL Server Management Studio Generate Scripts wizard, with triggers, collations, logins, owners and permissions included for the assessment.
4. Assess with Compass and fix or work around what it flags.
5. Create schemas, user-defined types and tables with primary keys through the T-SQL endpoint, for example with sqlcmd.
6. Load the data with AWS DMS. For continuous replication from SQL Server, AWS says to use the Aurora PostgreSQL endpoint rather than the Babelfish endpoint as the DMS target. The bcp utility, SSIS and the SSMS Import/Export Wizard also work for loads.
7. Create the remaining objects: check and foreign key constraints, defaults, triggers, indexes, views, then procedures.
8. Repoint and retest the application on port 1433.

aws rds create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name babelfish-pg16 \
  --db-parameter-group-family aurora-postgresql16 \
  --description "Babelfish enabled"

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name babelfish-pg16 \
  --parameters "ParameterName=rds.babelfish_status,ParameterValue=on,ApplyMethod=pending-reboot"

aws rds create-db-cluster \
  --db-cluster-identifier sales-babelfish \
  --engine aurora-postgresql \
  --engine-version "$AURORA_PG_VERSION" \
  --master-username postgres \
  --manage-master-user-password \
  --db-cluster-parameter-group-name babelfish-pg16 \
  --vpc-security-group-ids "$SECURITY_GROUP_ID" \
  --db-subnet-group-name "$DB_SUBNET_GROUP"

Then create the primary instance with aws rds create-db-instance against that cluster. Server-side code is only half the assessment. AWS recommends capturing the queries the application sends, with the SSMS XEvent Profiler or SQL Server Profiler's TSQL_Replay template, and running them through Compass too. Microsoft has deprecated SQL Server Profiler, so Extended Events is the longer-lived choice.

Path B: full conversion to native Aurora PostgreSQL

1. Assess and convert with DMS Schema Conversion, which supports SQL Server 2008 R2 to 2022 as a source and Aurora PostgreSQL 14 to 17 as a target, with optional generative AI conversion for objects its rules cannot handle. AWS SCT does the same as a standalone application and can also target PostgreSQL outside Aurora.
2. Review the converted code. T-SQL procedures that return result sets become functions, TRY ... CATCH becomes an EXCEPTION block, and identity, temp table and datetime handling change. The SQL Server to PostgreSQL migration guide lists the patterns, including the case-insensitive collation problem.
3. Create tables with primary keys on Aurora, holding back secondary indexes, foreign keys and triggers.
4. Prepare SQL Server for CDC. AWS DMS needs the Full or Bulk-logged recovery model, a full backup taken before replication starts, and MS-Replication or Change Data Capture enabled. Express edition is not supported as a source, and CDC needs Enterprise, Standard 2016 or later, or Developer edition.
5. Run a full-load-and-cdc DMS task, pause before cached changes are applied, build secondary indexes and foreign keys, then resume. The AWS Oracle to PostgreSQL walkthrough shows the task commands; only the source endpoint differs.
6. Change the application to PostgreSQL drivers and SQL, and test against production-sized data.

If you prefer open-source tooling for the schema and data, pgloader does the load in one pass; see SQL Server to PostgreSQL using pgloader. It does not capture ongoing changes, so it suits migrations that can stop writes for the final copy.

What neither path does for you

• SQL Agent jobs, linked servers and SSIS packages need new homes or rewrites. Babelfish runs T-SQL in the database; it does not run SQL Server's job scheduler.
• CLR assemblies have no equivalent on either path.
• Backups and restores follow Aurora and PostgreSQL methods. Babelfish has its own adapted dump and restore tooling, and it works differently from SQL Server's BACKUP.
• Performance has to be re-tested. Query plans come from the PostgreSQL planner in both cases.
• Security model: logins, roles and permissions need to be recreated and tested, and on Babelfish some Aurora authentication options are unavailable, as listed above.

Cutover and rollback

Both paths end the same way: freeze changes, stop writes, let DMS apply the last changes, reset sequences or identity values, switch the connection strings and smoke-test. Rollback is easier to plan with Babelfish, because the application still speaks T-SQL and could point back at SQL Server without code changes, provided the data written on Aurora is carried back. With a full conversion, rolling back means redeploying the previous application build as well as moving data. Either way, keep SQL Server intact and read-only until a pre-agreed decision date.

The portability trade-off, stated fairly

Babelfish is the fastest way off SQL Server for code you cannot easily change, and AWS includes it in Aurora. The trade-off is where you can run afterwards. Managed Babelfish is an Aurora feature. Leaving Aurora later means either converting the T-SQL then, or building and running the open-source Babelfish yourself on its patched PostgreSQL. Your application also stays tied to T-SQL and to the SQL Server driver ecosystem.

A full conversion costs more up front and gives you ordinary PostgreSQL. The same schema and code run on Aurora, RDS, your own servers or another cloud, which keeps hosting, support and version decisions open later. Neither choice is wrong. They suit different applications in the same estate, and the assessment should decide per application.

Deciding per application

Run the same short checklist for each SQL Server database before committing to a path:

• Who owns the code? For vendor software, check which databases the vendor supports before planning either route. If it already supports PostgreSQL, follow the vendor's path.
• How much logic lives in T-SQL? Little procedural code favours conversion, because the rewrite is small and the result is portable. Large bodies of procedures with no team to rewrite them favour Babelfish.
• What does Compass report? If the application depends on features Babelfish does not support, such as CLR routines or distributed transactions, Babelfish is out for that database until those dependencies are removed.
• Where might it run later? If running PostgreSQL outside Aurora is a realistic option, converting now avoids a second migration. PostgreSQL vs Aurora vs RDS sets out how the platforms differ.
• What is driving the date? An end-of-support date or a licence renewal can justify Babelfish first and conversion later. The SQL Server 2016, 2017 and 2019 support posts list the dates.
• Who will run it? A Babelfish database needs people who understand both T-SQL and PostgreSQL operations. A converted one needs PostgreSQL skills only.

The answer can differ between databases in the same estate. That is normal, and it is better than forcing one path on every application.

Where OSSeva fits

If the plan is Babelfish on Aurora, AWS is the right partner, and OSSeva is not the better fit: OSSeva supports community PostgreSQL, not Babelfish's modified build. If the plan is a full conversion, or native PostgreSQL that you may later run yourself, OSSeva for PostgreSQL fits: OSSeva assesses which path fits each application, supports the PostgreSQL cluster from the day you cut over on bare metal, VMs, any Kubernetes or any cloud account, and ships patched builds for versions past community end of life. Support is priced per cluster; book a discovery call for a quote. See SQL Server to PostgreSQL with OSSeva and, for moving off managed services later, cloud database repatriation.

Frequently asked questions

How do you migrate SQL Server to Aurora PostgreSQL?

Either turn on Babelfish for an Aurora PostgreSQL cluster and move the T-SQL schema and data to it, or convert the schema and code to native PostgreSQL with DMS Schema Conversion or AWS SCT and move the data with AWS DMS. Both paths use DMS for the data.

What is Babelfish for Aurora PostgreSQL?

An Aurora capability that lets PostgreSQL accept SQL Server client connections over TDS on port 1433 and run T-SQL, so SQL Server applications can move with fewer code changes. It is also an open-source project under the Apache 2.0 and PostgreSQL licences.

Does Babelfish support all T-SQL?

No. AWS documents differences from SQL Server and the project lists unsupported features, including CLR routines, availability groups and the BACKUP statement. Babelfish Compass reports which of your objects are affected.

Can I change the Babelfish migration mode later?

AWS says not to. The migration_mode is set when the cluster is created, and changing it afterwards can cost you access to the objects you created. Decide between single and multiple database mode before you start.

Is Babelfish available on RDS for PostgreSQL or self-managed PostgreSQL?

AWS documents Babelfish as a feature of Aurora PostgreSQL. Outside Aurora, the open-source Babelfish needs its patched PostgreSQL build and four extensions, which you build and operate yourself.

Is Babelfish lock-in?

Partly. The code is open source, so you are not locked to one vendor's licence, but the managed version is Aurora-only and your application stays in T-SQL. A full conversion to native PostgreSQL keeps more hosting options open.

Should I use AWS SCT or DMS Schema Conversion for SQL Server?

DMS Schema Conversion is managed inside AWS DMS and targets Aurora and RDS. AWS SCT is a standalone tool that supports more targets. For Babelfish, SCT produces assessment reports only.