spike: port adapter from pyodbc/ODBC to ADBC

[dataders]

Summary

Spike to replace the entire pyodbc/msodbcsql18 stack with ADBC (Arrow Database Connectivity) using the mssql driver from dbc, and remove the dbt-fabric dependency entirely to make dbt-sqlserver a standalone adapter.

Why: ODBC driver installation is the #1 pain point for dbt-sqlserver users across platforms. ADBC's mssql driver is a single binary installed via dbc install mssql — no ODBC driver manager, no msodbcsql18, no platform-specific setup.

Scope: SQL auth only, local Docker SQL Server, proving the adapter works end-to-end.

Changes

Python adapter (remove dbt-fabric dependency)

• setup.py — Remove dbt-fabric==1.9.6, add adbc-driver-manager>=1.9.0 + pyarrow>=20.0.0
• __init__.py — Remove dependencies=["fabric"] from AdapterPlugin
• sqlserver_credentials.py — Inherit from Credentials (was FabricCredentials); add build_adbc_uri() for go-mssqldb connection URIs
• sqlserver_connections.py — Inherit from SQLConnectionManager (was FabricConnectionManager); connect via adbc_dbapi.connect(driver='mssql', ...); add data_type_code_to_name() mapping Arrow type codes → SQL Server types
• sqlserver_adapter.py — Inherit from SQLAdapter (was FabricAdapter); inline Fabric's type conversion and SQL helper methods
• sqlserver_column.py — Inherit from Column (was FabricColumn); inline type labels and methods
• sqlserver_configs.py — Inherit from AdapterConfig (was FabricConfigs)

Macros (inline fabric macros with sqlserver__ prefix)

Since we removed dependencies=["fabric"], fabric macros are no longer in the dispatch chain. All ~25 fabric macros that sqlserver depended on were copied in with sqlserver__ prefix:

• Metadata — list_schemas, check_schema_exists, list_relations_without_caching, get_relation_without_caching, get_relation_last_modified
• Relation — make_temp_relation, get_drop_sql, rename_relation
• Schema — create_schema, drop_schema
• Columns — get_columns_in_relation, alter_relation_add_remove_columns
• Grants — apply_grants, get_show_grant_sql, get_grant_sql, get_revoke_sql
• Show — get_limit_sql (OFFSET/FETCH)
• Incremental — get_merge_sql, get_delete_insert_merge_sql, get_incremental_default_sql
• Snapshot — post_snapshot, get_true_sql, snapshot_hash_arguments, build_snapshot_table, snapshot_staging_table
• DDL — build_columns_constraints, build_model_constraints
• Utils (14 new files) — any_value, array_construct, cast_bool_to_text, concat, date_trunc, dateadd, get_tables_by_pattern, hash, last_day, length, listagg, position, safe_cast, timestamps

Seed loading fix

ADBC's mssql driver does not support parameterized queries with ? placeholders. Rewrote sqlserver__load_csv_rows to inline literal values directly into INSERT statements, with proper handling for NULL, booleans (is sameas true/false), numbers, and strings (with quote escaping).

Unit test macro fix

Updated unit_test_table.sql to pass column_name_to_quoted to get_expected_sql() (required by newer dbt-core API).

Test Results

Suite	Result
Unit tests	10/10 passed
dbt debug	10/10 passed
Functional tests	123 passed, 8 failed, 45 skipped, 1 xfailed

8 remaining failures (all known ADBC behavioral differences)

Test	Root Cause	Fixable?
4 grant tests	Need a test user/login in the database — not an ADBC issue	Yes, test setup
3 query comment tests	ADBC log format differs from pyodbc; tests match log output	Yes, needs investigation
1 timestamp naive test	ADBC returns Arrow timestamps with UTC tz; pyodbc returned naive datetimes	Yes, override test expectation

Known limitations (acceptable for spike)

1. SQL auth only — Azure AD/MSI/SP auth not implemented (go-mssqldb supports ?fedauth= for future work)
2. No parameterized queries — Seeds inline values; this may have SQL injection implications for seed data with malicious content (acceptable for trusted seed CSVs)
3. Query timeout — No direct ADBC equivalent for pyodbc's handle.timeout
4. Timestamp timezone — ADBC returns all timestamps as UTC-aware; may affect snapshot comparisons in edge cases

How to test locally

# Install dbc and ADBC mssql driver
uv pip install dbc
dbc install mssql
uv pip install -e .

# Start SQL Server (Azure SQL Edge for ARM Macs)
docker run -d --name sqlserver-test \
  -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD=YourPassword1 \
  -p 1433:1433 mcr.microsoft.com/azure-sql-edge:latest

# Run tests
export SQLSERVER_TEST_HOST=127.0.0.1 SQLSERVER_TEST_USER=sa \
  SQLSERVER_TEST_PASS=YourPassword1 SQLSERVER_TEST_DBNAME=TestDB \
  SQLSERVER_TEST_ENCRYPT=True SQLSERVER_TEST_TRUST_CERT=True
pytest tests/unit -v
pytest tests/functional -v --profile user

🤖 Generated with Claude Code

[axellpadilla]

@dataders , You should keep this driver core change isolated from others, if you can please use #628 as base for fabric adapter removal, I will production test the driver change myself if this helps on DBT fusion road but this needs to be behind a flag, it's a core change and should wait for a better schematic version update.

[dataders]

@dataders , You should keep this driver core change isolated from others, if you can please use #628 as base for fabric adapter removal, I will production test the driver change myself if this helps on DBT fusion road but this needs to be behind a flag, it's a core change and should wait for a better schematic version update.

hey @axellpadilla thanks for checking this out! FWIW, I have no plans to merge this. I was just vibe-coding out a thought experiment.

[axellpadilla]

@dataders , You should keep this driver core change isolated from others, if you can please use #628 as base for fabric adapter removal, I will production test the driver change myself if this helps on DBT fusion road but this needs to be behind a flag, it's a core change and should wait for a better schematic version update.

hey @axellpadilla thanks for checking this out! FWIW, I have no plans to merge this. I was just vibe-coding out a thought experiment.

Yeah thanks it's interesting, I hate having to install the driver!

[komjera]

Im not familiar with ADBC, and I realize that this might not be a PR intended to be merged, but I'm curious if any similar test has been made to migrate to mssql-python? They even support bulk copy since a couple of weeks ago

[axellpadilla]

Im not familiar with ADBC, and I realize that this might not be a PR intended to be merged, but I'm curious if any similar test has been made to migrate to mssql-python? They even support bulk copy since a couple of weeks ago

I was thinking into migrate my instance to mssql-python could hint you If i manage to it for you to use it (this repo is a little stale), bulk copy is no use because of how dbt works just executing the queries (not moving data), that said, I believe ADBC is the best bet if we want future fusion capabilities, or probably just allow both

[komjera]

@axellpadilla please do, would love to try that out if you manage to find time for it.

Regarding bulk copy I was thinking more in terms of other workflows that might run in the same environment as dbt where you would want a unified setup for connecting to sql server.

[axellpadilla]

Hi guys @dataders , @komjera, you can test #628 + mssql-python via a feature flag on this branch:
https://github.com/axellpadilla/dbt-sqlserver/tree/feat/mssql-python

I realized on CI that mssql is a little faster, but, it still required some installs:
https://github.com/microsoft/mssql-python/blob/main/README.md

Check CI results (using my patche branch where I merge experimental or personalized things, dont use it).
https://github.com/axellpadilla/dbt-sqlserver/actions/runs/23720168929

Im interested into ADBC if that can improve things even farther, if you can follow the same pattern of feature flag using this branch as base I will be happy to test it @dataders