11 posts tagged with "babelfish"

Babelfish stores everything in a standard PostgreSQL database (babelfish_db). Your T-SQL schemas, tables, stored procedures (compiled to PL/pgSQL internally), triggers, and views are all PostgreSQL objects underneath. This means the backup story for Babelfish is exactly the backup story for PostgreSQL: pgbackrest, WAL archiving, and point-in-time recovery.

This post documents how backups work on a live Babelfish 4.8.0 instance, using confirmed results from FoundryDB staging.

Loading data efficiently is one of the first things you need to sort out when migrating from SQL Server. Babelfish supports several bulk loading patterns natively, but the BULK INSERT statement is not one of them. This post documents what works, what does not, and the best alternatives, all tested live against Babelfish 4.8.0 on PostgreSQL 16.11.

For provisioning instructions, see the Babelfish getting started guide.

Dynamic SQL is one of the most heavily used features in real-world SQL Server applications. Stored procedures that build queries at runtime, parameterised searches, dynamic pivot tables, and flexible reporting queries all rely on it. If you are migrating from SQL Server to Babelfish, you need to know that these patterns work before you commit to the move.

This post documents six dynamic SQL patterns tested against Babelfish 4.8.0 on PostgreSQL 16.11, running as a FoundryDB managed service. Every test passed without modification.

SQL Server applications commonly rely on text search, from simple LIKE patterns to full-text predicates like CONTAINS and FREETEXT. If you are migrating to Babelfish, you need to know which of these work out of the box and which require changes.

This post documents every text search method we tested against Babelfish 4.8.0 on PostgreSQL 16.11, running as a FoundryDB managed service. Every query was executed and every result verified.

Babelfish speaks TDS, the SQL Server wire protocol. Any SQL Server driver connects to it on port 1433 without modification to the driver itself. The only required change from a typical SQL Server connection is disabling TLS on the TDS port: Babelfish 4.8.0 does not support TLS on TDS.

This post shows working connection code and confirms which features work, based on live tests against Babelfish 4.8.0 on PostgreSQL 16.11, running on FoundryDB staging.

Babelfish translates T-SQL to PostgreSQL internally. For most index operations and query tuning work, this is transparent: you write the same CREATE INDEX syntax you would use on SQL Server, and Babelfish creates the corresponding PostgreSQL index. Some SQL Server performance tooling does not map cleanly to the PostgreSQL layer, and it is useful to know where the boundaries are before you start profiling.

This post documents index behaviour and query performance tooling in Babelfish 4.8.0, based on confirmed results from live testing on a FoundryDB staging instance. All results use a 10,000-row table tested against PostgreSQL 16.11.

Babelfish for PostgreSQL lets you run SQL Server applications against a PostgreSQL backend with minimal code changes. Your application connects on port 1433 using the standard TDS protocol, sends T-SQL, and Babelfish translates the queries into PostgreSQL internally.

FoundryDB now offers Babelfish as a fully managed service. This post walks through provisioning, connecting, and verifying a working instance using confirmed results from Babelfish 4.8.0 on PostgreSQL 16.11.

Python developers working with SQL Server typically reach for one of two libraries: pymssql for direct TDS access, or SQLAlchemy for ORM-based workflows. Both work with Babelfish, but SQLAlchemy requires three specific workarounds due to differences in how Babelfish implements the TDS protocol.

This post covers both approaches with complete, working code tested against Babelfish 4.8.0 on PostgreSQL 16.11 running on FoundryDB staging. The pymssql section expands on driver-level coverage with additional tests for stored procedures and batch insert performance.

Babelfish promises SQL Server compatibility, but compatibility claims are only useful when grounded in tested behaviour. This post documents what actually works and what does not, based on systematic testing against Babelfish 4.8.0 on PostgreSQL 16.11, running as a FoundryDB managed service.

Every result below was verified by running the query and checking the output. Nothing here is speculative.

Babelfish supports a subset of SQL Server's security model. Some T-SQL user management commands work as expected, others fail with known limitations, and a few are not supported at all. This post documents every command we tested against a live Babelfish 4.8.0 instance on FoundryDB, with exact results.

The practical takeaway: manage your database users through the FoundryDB API, which handles user creation at the PostgreSQL level and avoids the current Babelfish limitations entirely.