The lakehouse is one protocol away: Trino, Databricks and Snowflake as query engines

[WaylandYang]

Three HTTP-protocol query engines beside Postgres, each behind the same QueryEngine trait:

• Trino (trino://, also presto://) — POST /v1/statement + nextUri paging. One catalog away from Iceberg, Delta Lake, Hive and Hudi, and Starburst speaks the same protocol.
• Databricks (databricks://) — SQL Statement Execution API with INLINE / JSON_ARRAY results and PENDING → SUCCEEDED polling; the path is the console's httpPath.
• Snowflake (snowflake://) — SQL API v2 with 202 → handle polling; programmatic access token or OAuth (key-pair JWT deliberately not yet).

The scheme picks the engine (engine_from_conn), so the data-source page keeps its single connection-string field; the shape is validated at registration with the exact form in the error. The SQL gate parses with the engine's own dialect (guard_sql_for), LIMIT wrapping and JSON Lines are shared, and string-typed values from Databricks / Snowflake are restored to numbers and booleans from the column type. The engine client has an explicit proxy policy (loopback and NO_PROXY direct, HTTPS_PROXY / HTTP_PROXY otherwise) because reqwest's Windows system-proxy detection routed loopback through the proxy. Migration 0021 widens the engine CHECK.

Tests: 17 new unit tests (connection-string parsing, dialect gates, JSON assembly, type coercion) and wiremock replays of each protocol including their error bodies. End to end against a stand-in Trino on the isolated deployment: register → test → grant → mount (schema document says Engine: trino) → chat runs query_data through the Trino path and answers with the lake's numbers. None of the three has run against a real cluster; follow-up issues ask for that.

Decision record 0018 (English, per the new convention) explains why Trino rather than format readers, why MaxCompute waits, and what is missing. README's Ontology-driven querying row and roadmap updated (English only, by request).

🤖 Generated with Claude Code