Supported engines

Airbrx supports three engines today: Databricks, Snowflake, and PostgreSQL. Each one is spoken in its own native wire protocol, which is what lets you change a hostname instead of changing a driver.

The three engines

MySQL and SQL Server are not supported. There is no code for either; the PostgreSQL adapter is the template they would be built from. If you need one of them, tell us — it changes how they get prioritized.

Why native protocol, not a vendor SDK

No Airbrx adapter uses a vendor SDK's client API to talk to your warehouse. The Databricks leg is hand-driven Thrift over raw HTTPS. The Snowflake leg is hand-rolled REST/JSON. The PostgreSQL leg speaks wire messages directly.

This is not a preference; it is what makes the product possible. An SDK can only ever be a client. To sit in the middle and be indistinguishable from the real service, Airbrx has to be the server on one side and the client on the other — answering a session-open request itself, synthesizing a status response, holding a client on a running poll while it fills a cache. That is the difference between a proxy and a wrapper, and it is why "no code changes, no refactoring" is a description rather than a promise.

The practical consequence for you: your driver, your connection string format, your credentials, and your existing warehouse-side grants all keep working. There is no Airbrx driver to install.

What is the same on every engine

The engine-specific code is the protocol. Everything above it is shared, so behavior does not fork by engine:

• The same rules engine, cache key derivation, and cache storage.
• The same invalidation model — markers keyed on rule and rule version.
• The same stale-while-revalidate behavior.
• The same per-request traffic log, feeding the same summaries and analytics API.
• The same deny rules, enforced before every cache decision.
• The same credential model — the Gateway holds no warehouse credentials of its own.

PostgreSQL specifics

PostgreSQL arrived after the two warehouse connections and works a little differently, because a Postgres client authenticates before it says anything else. The things worth knowing:

TLS is mandatory

A client that tries to skip the TLS upgrade — sslmode=disable — gets a clean error and the connection closes. It is never silently downgraded to plaintext. Set sslmode to require or stricter.

Routing

The Gateway resolves your tenant from the TLS SNI name. If your client sends SNI — most do — routing is automatic. Where it does not, the Gateway falls back to reading the database field as your gateway address, so psql "dbname=<your-gateway-address>" routes correctly too.

Three ways to authenticate, none of which hand us a credential

There is no fourth option where you store a warehouse username and password in your tenant configuration. That field does not exist in the schema. An auth mode is required — a PostgreSQL tenant without one is rejected at configuration time.

Cached credentials used to verify a returning connection carry a one-hour lifetime. That is your revocation window: if you change or revoke a password in the database, expect up to an hour before the Gateway stops accepting the old one.

Simple and extended query, and a connection that may never open

Both the simple and extended query protocols are supported, and both integrate with the cache. COPY is not supported.

The backend connection is opened lazily — only when a message genuinely needs the backend. A session where every query hits cache completes with no backend contact beyond whatever authentication itself required. On the extended query path, Parse and Bind are answered locally from a cached schema shape where possible, with the original messages replayed against the backend later if a cache miss forces a real connection.

Deploys drain rather than drop

A Postgres session is long-lived and stateful, so a Gateway deploy stops accepting new connections and gives in-flight sessions a bounded window to finish before closing stragglers. You should not see a query killed mid-execution by a routine deploy.

Where to go next

• PostgreSQL connection recipe — the connection strings, worked through.
• Connect your warehouse — adapter setup in the App.
• How the Gateway works — the request lifecycle these adapters share.