CryspIQ® vs data virtualisation
These two answer different questions.
- Data virtualisation asks: "How do I get to my data faster?"
- CryspIQ® asks: "Can I trust the answer?"
Data virtualisation leaves your data where it is and fetches the answer from each system every time you ask. You get whatever those systems say at that moment, mistakes included.
CryspIQ® keeps one trusted copy of only the data that matters. That data is checked and corrected once, and recorded with its business context, so every answer comes from the same reliable source. Right answer, every time.
Is CryspIQ® a data virtualisation platform?
No. CryspIQ® doesn't query your source systems each time someone asks a question. It loads the data that matters once, checks and corrects it, and stores it with its business meaning. Every answer then comes from that one trusted copy. If you're comparing CryspIQ® with a federated query, query-in-place, zero-copy or logical data warehouse product, this page sets out the difference.
What data virtualisation is
Data virtualisation (also spelled data virtualization) puts a query layer over the systems you already have. You don't move data into a warehouse. Instead, the query goes to the data. One query can reach across databases, data lakes, warehouses and applications, and the platform joins the results and returns them as if they came from one place. Many add a semantic layer to name the measures, and caching to speed up repeat queries.
The same approach is sold under several names: query federation, federated query, query-in-place, zero-copy analytics, a logical data warehouse, lakehouse federation, and some products described as a data fabric. The common thread is no data movement: the data stays in the source systems, and the platform reads it there at the moment you ask.
It solves a real problem well: getting at data spread across many systems without building a pipeline for each one first.
Getting to the data is not the same as trusting it
Faster access is valuable when people are waiting on data. But when the finance team spends month-end reconciling three versions of revenue, the data isn't the issue. The issue is that the numbers don't agree, and reaching those numbers faster doesn't change that.
That's the question CryspIQ® is built around: data you can sign off on, and the efficiency of getting it.
Where the two actually differ
Ask twice, get two answers. With virtualisation, each query goes back to the source systems. If a source changes between two queries, or a field is entered differently in two systems, the answer changes with it. In CryspIQ®, every report, dashboard and AI agent reads the same stored data, so they all give the same answer.
Mistakes travel with the answer. A federated query reports what the source systems say. Duplicate customers, a missing cost centre or a mistyped date come back in the result, and they come back every time. Whoever uses the result has to spot the problem and work around it. CryspIQ® assesses quality as data loads, so a problem is found and corrected once, on the way in, and everyone downstream gets the corrected version.
Meaning is applied when a query runs, not stored. A semantic layer over federated sources explains what the source tables mean each time a query runs. The tables themselves still carry each application's own structure and names. In CryspIQ®, the business definition is carried on the fact type and stored with the data. See CryspIQ® vs a semantic layer for why that matters to anything that reads the data directly.
One customer, or five. Querying five systems that each hold a customer record gives you five customer records, and matching them up is left to the query. CryspIQ® holds a single instance per party, enforced by the structure of the model.
Operational systems carry the load. A federated query runs against the systems the business operates on, unless the result is cached. CryspIQ® reads from those systems when data loads, so analytics and AI workloads don't add load to the ERP or CRM.
Replacing a source system. Federated queries and semantic definitions describe each application's own tables. Swap the CRM and those definitions have to be rebuilt, and the history that lived in the old CRM goes with it unless it's kept somewhere else. CryspIQ® holds business facts rather than one application's version of them, so a new application is a new mapping and history is unaffected.
History. Virtualisation shows what the sources hold now. If a source overwrites or deletes a record, the earlier value is gone. CryspIQ® keeps what it has loaded, so you can still answer what was true last quarter.
Side by side
| With data virtualisation | With CryspIQ® | |
|---|---|---|
| The question it answers | How do I get to my data faster? | Can I trust the answer? |
| Where the data lives | In each source system | One governed copy of the data that matters |
| How a question is answered | The query goes to the sources, every time | The query reads the trusted copy |
| Data quality | Whatever the sources hold, every time you ask | Checked and corrected once, as data loads |
| Business meaning | Applied by a semantic layer when the query runs | Stored with the data on the fact type |
| Master data | Matched in the query, if at all | A single instance per party, enforced by the structure |
| Same question, asked twice | Can return different answers | Returns the same answer |
| Load on operational systems | Queries run against them | Read when data loads, not when people ask |
| Replacing a source application | Rebuild the definitions that described it | Map the new source; history is unaffected |
| History | What the sources hold now | Kept as loaded |
| AI readiness | The agent gets the sources' version of the truth | The agent gets checked data with its business context |
Where data virtualisation is stronger
It's faster to start. Nothing has to be copied or mapped into a model before you can query. Point it at your sources and you can be joining them across systems quickly. That's a real advantage and we don't want to talk past it.
Live data. If you need what the source system says this second, querying the source is the most direct way to get it. CryspIQ® is as fresh as its last load.
Exploration and one-off questions. For a question you'll ask once, across systems you haven't modelled, federation is often the cheapest way to get an answer.
Data that can't be moved. Where regulation or contracts say data must stay in a particular system or country, querying it in place may be the only option.
The honest way to choose: virtualisation fixes access to data spread across many systems. It doesn't fix data that's wrong, duplicated or missing its meaning. If your problem is that people can't reach the data, virtualisation addresses it directly. If your problem is that people don't trust the answers once they have them, querying the same sources faster gives you the same untrusted answers, sooner.
Using both
They can work together. CryspIQ® can be one of the sources a federated query reaches, so trusted, governed data sits beside live operational data where both are needed. That's a sensible arrangement when exploration and live lookups stay in the federation layer, and the numbers the board, regulators and AI agents rely on come from CryspIQ®. See co-existence.