The SQL Server wire protocol

Check what is bound, not what is configured

The available flag under mssql_tds_dialect means configuration is complete. It is a precondition for starting a listener, not an observation that one is listening — and, as the next section explains, this adapter deliberately refuses to bind in states where it could not be safe. So check the flag, then the socket, then a real login.

# 1. What does this instance say about the adapter?
curl -s "https://$OC_HOST/v1/capabilities" | jq '.families.mssql_tds_dialect'

# 2. "available" means CONFIGURED, not "a socket is listening".
#    Check the socket too.
nc -vz $OC_SQL_HOST 1433

# 3. Then prove it end to end with a real login, not a port scan.
#    (sqlcmd, or the JDBC / Go snippets further down this page.)

1433 is the port SQL Server clients expect and the one used throughout this page, but the host and port your instance is published on are shown in the console once a listener exists. Use those. The limitations your own instance reports beside available are derived from its configuration, and are authoritative for it.

TLS is mandatory, and it fails closed

There is no plaintext path to this listener — not a discouraged one, not a flag, none. That is worth stating plainly because it changes what a misconfiguration looks like: a broken certificate does not produce a degraded connection, it produces no port at all. If nothing answers on 1433, check the certificate before you check the firewall.

It is enforced at four places, each of which fails closed:

• At startup. If the certificate and key are missing, empty or unloadable the listener does not bind, and the reason is logged. The check runs before the bind, so no port is ever presented as up.
• At PRELOGIN. A client that offers no encryption, or asks for it to be off, is answered with the protocol byte meaning encryption is required by the server and the connection is closed cleanly, before the login packet is read. It is not downgraded and not accepted-then-ignored.
• Against login-only encryption. Encrypting the login and then reverting to plaintext — which a real SQL Server will do — is rejected by design, not merely unimplemented. It protects the credential while streaming every query and every result row in clear, which for a database leaks exactly what the credential would have unlocked.
• In the type system. The command loop takes an encrypted stream that only a completed handshake can produce, so "no session runs unencrypted" is a compile-time property of the adapter rather than a rule someone has to remember.

Set encrypt=true and leave trustServerCertificate at false so your client actually validates the chain. The handshake itself is the TDS-framed variant that commercial SQL Server drivers require during negotiation; the stream switches to ordinary TLS records from the login packet onward.

This is the opposite of OriginChainDB's MySQL-wire adapter, which fails open — it binds without a certificate and then requires nothing. The two adapters behave differently on purpose, and a habit learned on one is the wrong habit on the other.

Connecting with a real client

Only drivers that have actually been driven against the engine appear here, at the versions they were driven at.

Java — mssql-jdbc 13.4.0 and 12.10.1

// Measured against mssql-jdbc 13.4.0 and 12.10.1 - 34 of 34 checks passed.
String url = "jdbc:sqlserver://" + System.getenv("OC_SQL_HOST") + ":1433"
           + ";databaseName="          + System.getenv("OC_DATABASE")
           + ";encrypt=true"            // mandatory - there is no other way in
           + ";trustServerCertificate=false"
           + ";hostNameInCertificate="  + System.getenv("OC_SQL_HOST")
           + ";loginTimeout=30";

try (Connection conn = DriverManager.getConnection(
        url, System.getenv("OC_DB_USER"), System.getenv("OC_DB_PASSWORD"))) {

    try (PreparedStatement ps = conn.prepareStatement(
            "SELECT TOP 50 id, customer_ref, amount_cents"
          + "  FROM invoices WHERE status = ? ORDER BY amount_cents DESC")) {
        ps.setString(1, "open");
        try (ResultSet rs = ps.executeQuery()) {
            while (rs.next()) {
                System.out.println(rs.getInt("id") + " " + rs.getString("customer_ref"));
            }
        }
    }
}

Go — microsoft/go-mssqldb 1.11.0

// Measured against microsoft/go-mssqldb 1.11.0 - 21 of 21 checks passed.
package main

import (
	"database/sql"
	"fmt"
	"net/url"
	"os"

	_ "github.com/microsoft/go-mssqldb"
)

func main() {
	q := url.Values{}
	q.Set("database", os.Getenv("OC_DATABASE"))
	q.Set("encrypt", "true")                  // mandatory
	q.Set("TrustServerCertificate", "false")  // validate the chain

	dsn := url.URL{
		Scheme:   "sqlserver",
		User:     url.UserPassword(os.Getenv("OC_DB_USER"), os.Getenv("OC_DB_PASSWORD")),
		Host:     os.Getenv("OC_SQL_HOST") + ":1433",
		RawQuery: q.Encode(),
	}

	db, err := sql.Open("sqlserver", dsn.String())
	if err != nil {
		panic(err)
	}
	defer db.Close()

	rows, err := db.Query(
		"SELECT TOP 50 id, customer_ref FROM invoices WHERE status = @p1", "open")
	if err != nil {
		panic(err)
	}
	defer rows.Close()

	for rows.Next() {
		var id int
		var ref string
		if err := rows.Scan(&id, &ref); err != nil {
			panic(err)
		}
		fmt.Println(id, ref)
	}
}

Worked, page-sized versions of both, plus the prepared-statement path, are in the TDS examples.

Credential models

A listener runs in one of two models, and the choice is not yours to make freely — it follows from whether the tenant has any database authorization to enforce: a database RBAC grant or a row-level security policy. Either one is enough; a row-security policy is not the lighter case.

The T-SQL boundary, exactly

A batch is parsed with a SQL Server grammar, the syntax tree is rewritten into OriginChainDB's SQL, and each statement is re-rendered and executed through the same engine every other surface uses. The rule the translator follows is soundness over coverage: anything without an exact equivalent is refused with a clear error and nothing executes. It never guesses, and it never returns a plausible wrong answer.

That makes the boundary easy to test and unpleasant to discover late. Here it is.

Translated

-- Every line below is rewritten and executed. Send it as an ordinary
-- SQL_BATCH, or as the statement text of a parameterized RPC.

SELECT TOP 20 [order].[id], [customer name]
  FROM [order]
 WHERE ISNULL([status], 'open') = 'open'
 ORDER BY [amount cents] DESC;

SELECT id,
       LEN(customer_ref)                         AS ref_len,
       CHARINDEX('-', customer_ref)              AS dash_at,
       IIF(amount_cents > 100000, 'large', 'small') AS bucket,
       CONVERT(NVARCHAR(32), amount_cents)       AS amount_text
  FROM invoices
 ORDER BY id
OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY;

Refused, cleanly

Each of these comes back as an error token naming the construct and, where one exists, the portable rewrite. Nothing runs, nothing is half-applied, and the connection survives.

-- Each of these is REFUSED with an explicit error. Nothing executes,
-- nothing is half-applied, and the connection stays open.

DECLARE @cutoff INT = 100000;          -- @variables are not modelled
SELECT @@VERSION;                      -- @@functions are not modelled
SELECT * INTO #recent FROM invoices;   -- # temp objects are per-session
GO                                     -- a client-tool directive, not a statement

MERGE invoices AS t USING staged AS s  -- use INSERT ... ON CONFLICT instead
   ON t.id = s.id WHEN MATCHED THEN UPDATE SET t.status = s.status;

SELECT DATEADD(day, -7, GETDATE());    -- no calendar timestamp type
SELECT CONVERT(VARCHAR(10), created_at, 112);  -- style codes are formatting
SELECT TOP 10 PERCENT * FROM invoices; -- no LIMIT equivalent
DELETE TOP (100) FROM invoices;        -- constrain with WHERE instead
SELECT * INTO archive FROM invoices;   -- SELECT ... INTO would create nothing

Three approximations to know about

These translate, and for ordinary inputs they agree with SQL Server. They are listed because for unusual inputs they do not:

• LEN does not reproduce T-SQL's trailing-space trim, so LEN('a ') counts the spaces.
• GETDATE() yields an ISO-8601 UTC string, because there is no datetime type to yield instead.
• CONCAT treats NULL as empty where T-SQL's + propagates it. Only reachable where both operands are provably string, which is the only case that translates at all.

Stored procedures: the distinction that costs money

TDS carries a remote-procedure-call path, and OriginChainDB serves the part of it every driver depends on: sp_executesql, sp_prepare, sp_execute, sp_prepexec and sp_unprepare. Seeing those names work is what makes people assume stored procedures work.

Also refused on this path, cleanly rather than mis-served: the server-side cursor family, OUTPUT value parameters (there is no variable-assignment surface that could produce one), bulk load, and multiple active result sets. Temporal parameter values decode best-effort in this preview — integer, float, bit, string, numeric and unique-identifier parameters are exact.

OriginChainDB does have procedures. They are written in a PL/pgSQL-shaped subset, created and called over the SQL endpoint or the PostgreSQL wire, and they are a genuinely different language. Here is what a small one looks like on both sides — note that nothing about the T-SQL version survives except its intent:

-- SQL Server (T-SQL). This does NOT run on OriginChainDB.
CREATE PROCEDURE dbo.settle_invoice @id INT, @settled INT OUTPUT
AS
BEGIN
    DECLARE @amount INT;
    SELECT @amount = amount_cents FROM invoices WHERE id = @id;
    IF @amount IS NULL
        THROW 50001, 'no such invoice', 1;
    UPDATE invoices SET status = 'settled' WHERE id = @id;
    SET @settled = @@ROWCOUNT;
END;

-- OriginChainDB. A different procedural language, so this is a rewrite -
-- not a port. Issue it over the SQL endpoint or the PostgreSQL wire.
CREATE PROCEDURE settle_invoice(IN p_id INT, INOUT p_settled INT)
LANGUAGE plpgsql AS $$
DECLARE
    v_amount INT;
BEGIN
    SELECT amount_cents INTO v_amount FROM invoices WHERE id = p_id;
    IF v_amount IS NULL THEN
        RAISE EXCEPTION 'no such invoice';
    END IF;
    UPDATE invoices SET status = 'settled' WHERE id = p_id;
    GET DIAGNOSTICS p_settled = ROW_COUNT;
END;
$$;

For anything larger, estimate the rewrite the way you would estimate a rewrite: by counting the procedures and reading them, not by assuming a compatibility layer will absorb them.

How far this has been proven

Interop is measured by driving Microsoft's own shipped drivers against the real accept loop — not a client written against our own encoder, which is how earlier claims about this adapter turned out to be wrong while every in-house test was green.

Thirteen consecutive rounds, all green, measured on 2026-09-07. What those rounds cover: connecting and logging in over the framed TLS handshake; DDL; insert; select with rows decoded and compared; the whole prepare / execute / unprepare family asserted through the driver's own prepared-statement handle rather than through our encoder; batch execution; and a wrong credential being refused. Both drivers are required — each one exercises framing, flush and row-count behaviour the other tolerates, and a single-driver run has already been shown to miss half of a defect set.

Limits, in one place

• The T-SQL procedural language is not implemented. No variables, no built-in globals, no control-flow batches, no GO, no temp tables, no T-SQL stored procedures, triggers or functions. Procedures are a PL/pgSQL-shaped subset and are a rewrite.
• This is a preview surface. It is not generally available, it is off on every instance unless someone turned it on, and it is not self-serve.
• TLS is required absolutely. No certificate means no listener, and a client that will not encrypt is refused before it can log in.
• Server-side cursors, bulk load and multiple active result sets are refused — cleanly, but refused. So is calling a user stored procedure, and so are OUTPUT value parameters.
• Date and time arithmetic does not translate. There is no calendar timestamp type behind this surface.
• Interop is verified, not continuously verified, against the three driver versions named above and no others. Other TDS clients may work; they have not been measured, so we do not claim them.

If any of that is disqualifying, the same data is reachable today over the SQL endpoint and the PostgreSQL wire, both of which are ordinary supported surfaces with none of the caveats on this page.