SQL Server (Babelfish)

Babelfish for PostgreSQL provides SQL Server wire-protocol compatibility, letting you connect SQL Server clients and run T-SQL queries without modifying your application.

How it works

Under the hood, a SQL Server service is a managed PostgreSQL 16 engine with the Babelfish extensions loaded. Babelfish exposes a TDS (Tabular Data Stream) endpoint on port 1433, the same wire protocol that Microsoft SQL Server speaks. Your SQL Server drivers, SSMS, and sqlcmd connect to it unchanged.

When a query arrives over TDS, Babelfish parses the T-SQL, translates it into an equivalent PostgreSQL plan, and the PostgreSQL engine executes it against the shared on-disk storage. The result set is then streamed back to the client over the same TDS session. Because the data lives in ordinary PostgreSQL relations, you also get dual access: a native PostgreSQL client can connect to the very same database directly on port 5432, bypassing the translation layer entirely.

Babelfish: SQL Server (TDS) over PostgreSQL

DUAL ACCESS TDS :1433 and native PG :5432

SQL Server appTDS:1433 →BabelfishT-SQL → PG→PostgreSQL 16:5432

SQL Server app (TDS)Babelfish :1433PostgreSQL 16 engineT-SQL → PG translationnative PG :5432 (dual access)

This dual-protocol model is what makes Babelfish a practical migration target. You can point existing SQL Server applications at the TDS endpoint with little or no code change, while new services, analytics tools, and the broader PostgreSQL ecosystem reach the same data natively over 5432. You are never locked into one protocol, and there is no separate replication step between the two views: it is one engine, one copy of the data, two front doors.

Connecting

Two ports are available:

Port	Protocol	Client
1433	TDS (SQL Server wire)	SQL Server drivers, SSMS, sqlcmd
5432	PostgreSQL	psql, JDBC, all PostgreSQL clients

SQL Server clients

# sqlcmd
sqlcmd -S HOST,1433 -U USER -P PASS -Q "SELECT @@VERSION"

# Connection string (.NET / ADO.NET)
Server=HOST,1433;Database=defaultdb;User Id=USER;Password=PASS;Encrypt=true;TrustServerCertificate=false;

# JDBC (SQL Server driver)
jdbc:sqlserver://HOST:1433;databaseName=defaultdb;user=USER;password=PASS;encrypt=true;

PostgreSQL clients

PGPASSWORD=PASS psql "host=HOST user=USER dbname=defaultdb sslmode=verify-full"

T-SQL Compatibility

Babelfish supports a large subset of T-SQL syntax including:

• SELECT, INSERT, UPDATE, DELETE, MERGE
• Stored procedures (CREATE PROCEDURE)
• Functions (CREATE FUNCTION)
• Triggers (CREATE TRIGGER)
• SQL Server data types (NVARCHAR, DATETIME, UNIQUEIDENTIFIER, BIT, etc.)
• sys. catalog views (partial emulation)
• INFORMATION_SCHEMA views
• SET options (NOCOUNT, ANSI_NULLS, etc.)

Common SQL Server idioms work as expected: TOP, OUTPUT clauses, table variables, temp tables (#tmp), IDENTITY columns, TRY...CATCH error handling, and the @@-prefixed session functions such as @@ROWCOUNT, @@IDENTITY, and @@VERSION. Object names are case-insensitive on the TDS side, matching SQL Server behaviour.

Database layout: single-db vs multi-db

Babelfish runs in one of two migration modes, fixed when the service is created:

• single-db maps one SQL Server database onto one PostgreSQL database. This is the simplest model and is the default for new services.
• multi-db lets a single instance present several logical SQL Server databases, each isolated under its own schema, closer to a multi-database SQL Server instance.

The mode determines how three-part names (database.schema.object) resolve, so it is worth choosing up front based on how your application addresses its databases.

Known Limitations

Not all SQL Server features are supported. Common gaps:

Feature	Status
SQL Server Agent jobs	Not supported
Linked servers	Not supported
CLR integration	Not supported
Full-text search	Not supported
OPENROWSET / OPENDATASOURCE	Not supported
Distributed transactions (MSDTC)	Not supported
Change Data Capture (CDC)	Not supported
FOR XML clauses	Limited support
Spatial data types	Limited support

For the full compatibility matrix, see the Babelfish documentation.

Migrating from SQL Server

Because Babelfish speaks TDS, most applications migrate by changing only the connection string to point at the 1433 endpoint. A typical path is:

1. Assess. Run your schema and a representative workload against the Babelfish Compass tool (or against a test service) to find any T-SQL the translation layer does not yet support.
2. Adjust. Rework the small number of unsupported constructs (for example, replacing a linked-server query or a CDC dependency) using the gaps listed above as a checklist.
3. Load schema and data. Apply your T-SQL DDL over the 1433 endpoint, then bulk-load data with bcp, sqlcmd, or any standard SQL Server tooling.
4. Cut over. Repoint the application at the managed endpoint. Existing SQL Server drivers, ORMs, and connection strings keep working.

The dual-access model helps here too: during and after migration you can use native PostgreSQL clients on 5432 for bulk ETL, monitoring, and PostgreSQL-native tooling without touching the application's TDS path.

Database Users

Create a user with SQL Server-compatible credentials:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/database-users \
  -H "Content-Type: application/json" \
  -d '{"username": "app_user", "role": "admin"}'

Configuration

Babelfish runs on top of PostgreSQL. PostgreSQL-level tuning applies:

curl -u admin:password -X PATCH \
  https://api.foundrydb.com/managed-services/{id}/configuration \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "max_connections": "200",
      "shared_buffers": "2GB"
    }
  }'

Backups

Backups use pgBackRest on the underlying PostgreSQL instance. PITR is available to any second within the retention window:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/restore \
  -H "Content-Type: application/json" \
  -d '{"restore_point": "2026-03-15T14:30:00Z", "target_service_name": "restored-mssql"}'