Multi-Database Engine

Federated Multi-Database Execution

Query, join, and aggregate metrics across completely separate physical databases—such as joining a PostgreSQL transactional store with a MySQL analytics warehouse—using the unified OrchaFusion execution engine.

How OrchaFusion Works

In enterprise architectures, data is rarely siloed in one place. User accounts may live in PostgreSQL, order logs in MySQL, and historical inventory records in Microsoft SQL Server. OrchaFusion acts as a distributed federator, pulling data partitions concurrently and performing in-memory WASM merges.

The alias.table Naming Syntax

Each connected database configuration is assigned an alias (e.g. crm, billing, warehouse). Agents address tables using standard dot notation:

sql

SELECT 
  crm.users.name,
  crm.users.email,
  SUM(billing.invoices.amount) AS total_spent
FROM crm.users
JOIN billing.invoices 
  ON crm.users.customer_id = billing.invoices.user_id
WHERE billing.invoices.status = 'PAID'
GROUP BY crm.users.name, crm.users.email
ORDER BY total_spent DESC
LIMIT 10;

Cross-Database Joins & Federation

When executing cross-database joins, OrchaFusion optimizes query pushdown by executing the individual subqueries on their native dialect database first, then streaming the result sets into an in-memory Apache DataFusion table partition to finalize the join.

Graph BFS Join Pathing Across Schemas

Relationships can span across database boundaries. If you link crm.customers.id to billing.subscriptions.customer_id in the Semantic Modeler, the BFS pathing engine automatically bridges the two engines when users query high-level terms.

Predicate Pushdown & Performance

WHERE clauses, aggregations, and limit expressions are pushed directly down to the source database engines to minimize network overhead and memory consumption.