Python & JDBC

snowflake-connector-python · databricks-sql-connector · SQLAlchemy · JDBC

For service code, ETL jobs, and ML pipelines: change one parameter in your connector setup. The official Snowflake and Databricks Python connectors work unchanged, and you can read the X-Airbrx-* response headers right from the cursor session — handy for asserting cache behavior in tests.

snowflake-connector-python

Replace the account parameter with your gateway address. Everything else — credentials, warehouse, database, schema — stays the same.

Before
import snowflake.connector

conn = snowflake.connector.connect(
    user="analytics_runner",
    password=os.environ["SF_PWD"],
    account="your-account",
    warehouse="REPORTING_WH",
    database="ANALYTICS",
)
After
import snowflake.connector

conn = snowflake.connector.connect(
    user="analytics_runner",
    password=os.environ["SF_PWD"],
    account="your-slug.gateway.airbrx.ai",
    warehouse="REPORTING_WH",
    database="ANALYTICS",
)

databricks-sql-connector

Before
from databricks import sql

conn = sql.connect(
    server_hostname="dbc-1234567890.cloud.databricks.com",
    http_path="/sql/1.0/warehouses/abc123",
    access_token=os.environ["DBX_TOKEN"],
)
After
from databricks import sql

conn = sql.connect(
    server_hostname="your-slug.gateway.airbrx.ai",
    http_path="/sql/1.0/warehouses/abc123",
    access_token=os.environ["DBX_TOKEN"],
)

SQLAlchemy

Update the host portion of the connection URL. Both the Snowflake dialect (snowflake://) and the Databricks dialect (databricks://) accept the gateway address transparently.

Before
engine = create_engine(
  "snowflake://user:pwd@your-account/"
  "ANALYTICS?warehouse=REPORTING_WH"
)
After
engine = create_engine(
  "snowflake://user:pwd@your-slug"
  ".gateway.airbrx.ai/ANALYTICS"
  "?warehouse=REPORTING_WH"
)

Generic JDBC (Java callers)

Replace the host in the JDBC URL — same shape as the DBeaver recipe. The Snowflake and Databricks JDBC drivers are wire-compatible with the Gateway.

Authentication

For interactive jobs and service flows, you have two options:

Verify cache from your driver session

Both connectors expose the response metadata of the most recent statement, including X-Airbrx-* response headers. Useful in tests and observability hooks:

cursor.execute("SELECT region, sum(amount) FROM orders GROUP BY region")

# Snowflake connector
metadata = cursor._connection.rest.token  # internal — see SDK docs

# Cleaner: use a session-level handler that captures the headers
print(cursor.sfqid)            # query id
print(cursor.headers.get("X-Airbrx-Cache-Status"))  # HIT or MISS
print(cursor.headers.get("X-Airbrx-Rule-Id"))

For service code, log a one-line trace per query if you want a steady signal of cache effectiveness:

# Per-statement trace from a Python service orders.aggregate.by_region | cache=HIT rule=cache-orders-1h latency=9ms orders.aggregate.by_region | cache=MISS rule=cache-orders-1h latency=418ms

Notes worth knowing

Where to go next

Ready to wire your service through the Gateway?

Airbrx is in private preview. Create an account and we'll set you up.

Create an account