The Data Fabric answers questions across your systems by reading the data in place. When a system needs a prepared, checked copy delivered on time, the Backbone moves it. Both use one catalog, one lineage record and one set of access rules.
Connect, catalog, ask, and read the answer from the systems themselves.
The Data Fabric connects to the systems you run, catalogs what is there, and answers questions by reading the data in place. A question can come from a SQL editor, a dashboard, or ChatLima, the assistant that answers questions in plain language. The data stays in the system that owns it.
A question that spans several systems is split by the query planner into one small query per system. Each system runs its part and returns only the rows that match. The platform merges the parts into one answer. This is called a federated query, and sending each system only its filter and its columns is called pushdown.
Every question passes the access policy before it runs, and its lineage is recorded as it runs. The same catalog, lineage record and access rules serve the Backbone when data has to move.
One rule, the common cases, and what a copy costs.
The rule is short. Read in place for questions, dashboards and assistants. Move the data when a system needs a prepared, checked copy inside a time window, when a calculation is too heavy to run at query time, when a fixed snapshot is required, or when a system is being migrated or retired. The table applies the rule to the common cases.
| What you want to do | Read it in place (Data Fabric) | Move it (Backbone) | Why |
|---|---|---|---|
| Ask questions, build dashboards, use ChatLima | Yes | — | The data is read where it lives and the answer comes back in seconds. The data stays in the source system. |
| Feed a planning application | — | Yes | Planning engines load a prepared dataset inside a time window. They need the data delivered, checked and on time. |
| Calculate at MRP scale | — | Yes | Material requirements planning (MRP) explodes a bill of material with up to 20 levels for millions of item-plant combinations. That is heavy computation, which is what the parallel engine is for. |
| Keep a month-end or regulatory snapshot | — | Yes | An auditor needs a fixed copy with a hash, kept as evidence. |
| Archive, offload or retire a system | Read the archive | Move it once | The Backbone moves the history. The Fabric keeps it readable afterwards. |
| Migrate to a lakehouse | — | Yes | Large volume, reconciled table by table, then kept current with change capture. |
| Send a partner feed on a schedule | — | Yes | The partner needs a file or a message at an agreed time, in an agreed format. |
| Answer a one-off question for an audit | Yes | — | The question is asked once. The answer comes from the source itself, with its lineage recorded. |
A copy costs three things, and each one is worth paying for a reason the table names. When none of the reasons applies, the question is answered in place and the three costs are avoided.
| What a copy costs | What it means | When the cost is worth paying |
|---|---|---|
| Storage | The copy occupies space in a warehouse or lakehouse and grows with every refresh. | A system must read a prepared dataset at its own pace inside a time window, such as a planning engine before its run. |
| A pipeline to maintain | Someone owns the schedule, the tests and the fixes for as long as the copy is used. | The calculation is too heavy to run at query time, or must finish before a business deadline. |
| A second place to govern | Access rules, quality rules and lineage apply to the copy as well as to the source. | A fixed snapshot is required as evidence, or a system is being migrated or retired and its history must live somewhere else. |
Forty-plus connectors, grouped by the kind of system they reach. SAP and Oracle are read through the interfaces each vendor supports.
The connector SDK is GA in Python, JavaScript and Java, and in beta in Scala. A connector built with it declares its schema, reads in batches from a marker column, can stream changes, and can write back where the system allows it. On the showcase estate a 3PL webhook connector was built in 4 days and registered 72 endpoints.
The same question, the same planner, and the interface each vendor supports.
An ERP holds orders, stock, materials and finance, and each vendor sets rules for how other software may read it. The table follows one question through SAP and through Oracle: what is sent to each system, what comes back, what the technical user needs, and what stays where it is.
| SAP ECC and S/4HANA | Oracle E-Business Suite and Oracle ERP | |
|---|---|---|
| What is sent to the system | The filter, for example orders since 1 September, and the list of columns, translated into the terms of the released SAP interface for that table or view. | The filter and the list of columns, as a SQL query that the Oracle database runs itself. |
| What comes back | The matching rows and the chosen columns only. On the showcase estate a month of order lines returned 841K rows and 48 MB from a table of 22M rows. | The matching rows and the chosen columns only. A large result is read in partitions, several at a time. |
| What the technical user needs | An RFC user with read authorisations for the tables and views in scope. Reads go through released interfaces; the interfaces SAP restricts are left out. | A read-only database user with SELECT grants on the tables in scope. The database keeps its standard setup. |
| What stays in place | Everything else: the full tables, the history, and the columns the question did not ask for. | Everything else: the full tables, the history, and the columns the question did not ask for. |
| Load on the system | One filtered read per question. Repeated questions are served from the cache. The S/4HANA connection on the showcase estate moves 32 GB a day across 4,218 tables at 42 ms p99. | One SQL query per question, capped per connection. The Oracle ERP connection on the showcase estate moves 18 GB a day across 2,891 tables. |
Workers, response times and the cache, with each figure explained.
Three things decide how fast a question is answered: how much of the work each system does itself, how many query workers are available, and whether the answer is already in the cache. The figures are from the showcase estate.
| Measure | Figure | What it means |
|---|---|---|
| Query workers | 4 → 12 in 90 s · ceiling 20 | Four Trino workers run at rest. Under load, eight more are added within 90 seconds. The ceiling is twenty. |
| Response time at 1,284 concurrent users | p95 1.4 s · p99 3.1 s | 95 of every 100 questions were answered within 1.4 seconds, and 99 of every 100 within 3.1 seconds. |
| A question across four systems | 2.1 s | SAP, Oracle, the WMS and a 3PL API, each answering its part, merged on the platform. |
| Cache | 74% hit rate · £1,840 saved | In February 2026, 74 of every 100 questions were served from the cache, saving £1,840 of compute against £84 of storage. |
| Saved results for busy dashboards | 0.08 s | A saved result is a table refreshed on a schedule for the busiest dashboards. It is served in 0.08 seconds. Live views fed by change capture pass through uncached on purpose. |
Column by column, from the execution itself.
Lineage is the record of where a number came from: which source columns fed which view, and which view fed which report or API. Because each question and each pipeline runs on the platform, the lineage is recorded from the actual execution, column by column. There is no separate scan to schedule and no diagram to keep up to date.
An example from the showcase estate: the column NETWR in SAP table VBRP feeds the column net_revenue_gbp in the certified view v_net_revenue, which feeds the Net-Revenue API. A certified view is a table that has passed its tests and is marked as safe to use. The platform recorded that chain when the view was built and each time it was queried.
Impact analysis reads the same record. When three pipelines were held during the ANO-001 incident, the incident card already listed the 84 downstream subscribers of the affected data product. OpenLineage carries the same lineage to the catalog you already run. OpenLineage on the standards matrix →
One catalog, one access policy, one set of quality rules.
The platform keeps one set of rules, and applies it whether data is read in place or moved. A pipeline on the Backbone inherits the catalog, the access policy, the PII tags and the quality rules the fabric already uses, so adding the Backbone adds no second place to govern.
Every table, view, pipeline and data product is in one register. The showcase estate discovered 4,284 assets in week 1.
Role- and attribute-based rules at row and column level, applied before a question runs and inside every pipeline. The same question gives three users three correct answers. Every access is recorded.
Personal data is tagged when it is discovered and masked by role. An erasure request clears it from the cache as well: 47 minutes on the showcase estate.
Rules are checked on the rows a question reads and on the rows a pipeline moves. A pipeline on the Backbone inherits the rules the fabric already applies.
The trust center: security, privacy operations and certifications with dates →
Each system receives one filtered query for its part of the question and returns only the matching rows. Repeated questions are served from the cache. On SAP the read goes through the released interfaces with an RFC user; on Oracle it is a SQL query run by a read-only database user. Reads can be capped per connection.
When a system needs a prepared, checked copy inside a time window, such as a planning engine before its run. When a calculation is too heavy to run at query time. When a fixed snapshot is required as evidence. When a system is being migrated or retired. In every other case the question is answered in place.
Yes. Both use the same catalog, lineage record, quality rules and access policy, so a pipeline added later inherits what the fabric already set up. The showcase estate connected five sources in four days, ran its first federated query on day 4, and moved its pipelines onto the Backbone in week 4.
Each system runs its part inside itself. The matching rows travel to the platform’s query workers, are merged in memory, and the answer is returned. A cached answer is kept on the platform for repeated questions, and an erasure request clears the cache as well.
The access policy decides, row by row and column by column, from the person’s role and attributes. A 3PL partner sees its own shipments only. A key account sees its own delivery performance. Personal data is masked by role. Every access is recorded.
A thirty-minute walkthrough on your systems: one question, answered in place, with the lineage and the access rules shown as it runs.
