Query Forge: federated SQL across agents, without a warehouse

Cross-database joins usually mean a warehouse, an ETL job, or a spreadsheet stitch. Query Forge is the other option: one JDBC URL into Core Hub, schemas that map to the SQL-capable agents you already run, and queries that push filters down the same Query Studio path. No new data channel. No write path.

Here is the why, when, what, and how for Query Forge as it ships today.

Why

Analysts and BI tools need one SQL surface across systems that already sit behind Gluesync agents. Building another copy of the estate is expensive. Opening every database to every laptop is worse.

Query Forge turns Core Hub into that surface. External JDBC clients (DBeaver, DataGrip, Tableau, a dashboard, a script) run one statement that spans several SQL-capable agents. Query Studio stays the in-portal workbench for a single agent. Query Forge is the external gateway for federation.

Reads reuse the permissioned Query Studio execute path. The engine only sees rows the caller is already allowed to read. Federation does not invent a second customer data path.

When

Reach for Query Forge when:

• You need a cross-agent JOIN (or multi-schema SQL) from a standard JDBC or BI client.
• Agents are already connected and SQL-capable, and you want query access without standing up a warehouse.
• Auth must stay per-user (your Core Hub identity and scopes), on a read-only execution path.
• You reach Core Hub through Gluesync Connect the same way you reach the API. Connect proxies; configuration does not fork for "Connect vs local."

Stay in Query Studio (or skip federation) when:

• You are exploring one agent from inside the Control Plane.
• The workload needs writes. Query Forge runs through Query Studio's read-only path.
• The query has no usable filter against a huge remote table. That table is fetched before the join; pushdown selectivity matters.
• You need native DATE / TIMESTAMP typing today. Docs currently expose date/time as text (ISO strings still compare and sort).

What

Unit of access. Each SQL-capable agent (pipeline + agent) becomes a schema. Tables under that agent become tables under that schema.

Schema naming.

• Single SQL-capable agent in a pipeline: schema equals the pipeline name (for example sales.orders).
• Multiple SQL-capable agents: disambiguated names (for example sales__pg.orders).
• Identifiers are case-insensitive.

Driver. Query Forge ships a dedicated driver (JAR) named gluesync-unified-jdbc that you can get right from your Core Hub by following the Query Forge setup wizard. Connection URL: jdbc:gluesync://<host>:<port>.

Auth (as yourself). No shared service token.

• SSO / OIDC: set a token connection property, or username __token__ with the token as password. Session token or Personal API Token (gsp_…). PAT is the recommended choice for a JDBC client you configure once.
• Local account: Core Hub username and password (exchanged for a token behind the scenes).

Pushdown. Column projection; comparisons (=, <>, <, <=, >, >=), IS NULL / IS NOT NULL, LIKE, and AND / OR / NOT. Complex IN lists and column-to-column comparisons stay central after fetch. Types come from agent schema metadata for aggregations and typed comparisons.

Security. Per-user schema visibility. Bad credentials fail the connection. Read-only. Put TLS in front (reverse proxy or platform termination).

Query Forge is not a CDC bus. Connect does not carry CDC row data for this path. It proxies the Core Hub API. Pipelines still move the data; Forge lets you query what those agents already expose.

How

1. Ensure SQL-capable agents exist and the caller can query them (same scopes as Query Studio).
2. Add gluesync-unified-jdbc to the client classpath.
3. Connect with jdbc:gluesync://<host>:<port> (docs example: jdbc:gluesync://corehub.example.com:8765).
4. Authenticate (local user/password, or __token__ / token + gsp_…).
5. Browse schemas: one per accessible SQL-capable agent.
6. Write federated SQL:

SELECT c.name, COUNT(o.id) AS order_count, SUM(o.total) AS revenue
FROM crm.customers c
JOIN sales.orders o ON o.customer_id = c.id
GROUP BY c.name
ORDER BY c.name;

Docs

• Query Forge — driver, auth, pushdown, security

Connect the driver. Run the join. That is the shape.

(Follow-up next week: AI as SQL on the same jdbc:gluesync:// wire — ask in English, review proposed_sql, you still run it.)