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.

The analyzer you assign to a field determines how text is broken into tokens at index time and at query time. Choosing the wrong one produces surprising results: searches that miss obvious matches, or matches that should not have ranked at all. This post compares the built-in English and standard analyzers, then builds a custom analyzer with synonym support.

All examples were tested against OpenSearch 2.19.1 on FoundryDB staging.

OpenSearch has a native snapshot API that writes index data to remote storage. FoundryDB wraps this API so you can trigger, list, and restore backups without configuring S3 credentials, IAM roles, or snapshot repositories manually. This post documents the backup flow using real metadata from a test run against an OpenSearch 2.19.1 cluster.

All commands use YOUR_SERVICE_ID and YOUR_API_TOKEN as placeholders. The FoundryDB API base is https://api.foundrydb.com.

OpenSearch's security plugin provides index-level permissions, field-level exclusions, and field masking out of the box. All of these are configurable through the Security REST API, which means you can automate role provisioning in CI/CD pipelines without touching the Dashboards UI. This post documents two concrete access control scenarios tested on a live OpenSearch 2.19.1 cluster managed by FoundryDB, with real HTTP responses showing enforcement in action.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders. Note that the Security API uses the _plugins/_security prefix.

BM25 is precise on exact terms but blind to meaning. Vector search is rich in semantics but can return spurious matches when query and document happen to point in similar directions by coincidence. Hybrid search combines both signals. This post shows how to configure a Reciprocal Rank Fusion (RRF) pipeline in OpenSearch 2.19.1 and documents the difference in results across three approaches, using real scores from a FoundryDB-managed cluster.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.