Cross-system joins without a warehouse
Query Engine Team · May 21, 2026 · 9 min
The usual answer is a warehouse
Joining ERP, CRM, and database records traditionally means building a warehouse: stand up storage, write ETL for every source, schedule loads, and accept that your reports are only as fresh as the last sync. That is a lot of infrastructure to answer a question that spans two systems.
Normalize, then compose
UQL normalizes every source into collections and fields. A saved report can then express a join across system boundaries declaratively. The planner pushes filters and aggregation down to each source where the engine supports it, fetches only what it needs, and composes the results — no staging warehouse required.
Pushdown where it counts
Pushdown is what keeps cross-system queries practical: filtering NetSuite transactions on the NetSuite side and SQL Server rows on the SQL side means the engine assembles small, relevant result sets instead of dragging full tables across the network.
When you do want to land data
Sometimes you genuinely want materialized results — for heavy dashboards or historical snapshots. The built-in PostgreSQL workspace lets a pipeline land derived tables inside your own tenant, which you can then query like any other source. You get a warehouse only where it earns its keep.