What is data federation vs a data warehouse?

The distinction matters practically for construction teams deciding how to get intelligence from their project data.

Data warehouse approach:

• All data is extracted from source systems (P6, SAP, Procore, IFC) and loaded into a central database on a schedule.
• A data engineering team builds and maintains the ETL pipelines.
• The warehouse is always a snapshot — as soon as a P6 update or an Aconex RFI comes in, the warehouse is out of date until the next load.
• Setup typically takes months and requires significant data engineering resource.
• The schema must be designed upfront; adding a new source means a new ETL pipeline.

Data federation approach (what Bildstak uses):

• Data stays in the source systems. Bildstak queries each source directly when a question is asked.
• No migration project and no ETL pipelines to maintain.
• The answer reflects the live state of every source — a schedule update in P6 is visible in the next query.
• Adding a new source means connecting a new integration, not rebuilding a pipeline.
• The AI analyst and the federation layer handle the join logic so the team does not need a data engineer.

Trade-offs — federation requires live API access to source systems, so if a system is offline the query may be incomplete. A warehouse can answer historical queries faster once built. For construction projects, where currency of data and speed of deployment matter more than historical depth, federation is typically the better model.

Bildstak's federation layer uses the IFC GlobalID as the universal join key, so records from systems that were never designed to talk to each other are linked automatically.