Imagine an analytics engineer who needs current order status from an operational Postgres database joined to historical revenue facts in a warehouse and clickstream Parquet in a data lake. Today that means three pipelines, three copies, and a staleness problem.
SemanticFed is designed to make that a single query. You register each source once, model the join in the semantic layer, and write one SQL statement. The federation engine plans the query, pushes predicates and aggregations down to each source so only the rows that matter move, and stitches the results together in memory.
Because the data stays in place, results reflect the live operational system, and there is no nightly pipeline to babysit. The same model powers your BI tool, your notebook, and your API.
This is a pre-launch scenario — illustrative of the experience SemanticFed is being built to deliver, not a record of a real deployment.
Do it yourself
Register your sources, model the join once, then compose a single federated query across an operational database, a warehouse, and a lake — and inspect the run that resolved it.
Open the Registry and register each system you want to query — your operational database, your warehouse, and your lake — giving each an endpoint and a credential reference.
You should see: Each source appears in the Registry with its connector kind and a connectivity status.
Ready to make this your story?
