Reuben Castellano, the chief data officer of a large state government, spent three years and a great deal of money building one central data warehouse to "unify all agency data." It was supposed to be the single source of truth. Instead it became the single source of bottleneck. His small central team could not possibly understand the Department of Transportation's road-sensor data, the Health Department's clinical records and the Tax Department's filings all at once. Every new dataset waited months in a queue. Domain experts who actually understood the data were not allowed to publish it. By year three, frustrated agencies were quietly building their own shadow systems, the exact fragmentation the warehouse was meant to end. "I tried to centralize everything," Reuben admitted, "and ended up owning all the problems and none of the knowledge."

This lesson is about two architectural answers to Reuben's failure: data mesh and data fabric. As an agency technology leader, you are deciding how data is owned, shared and made AI-ready across many departments that will never fully merge. These two ideas are constantly confused and frequently mispitched. Understanding the difference, and that they are complementary rather than competing, is what separates a coherent platform strategy from another expensive warehouse.

The Pyramid That Collapses Under Its Own Weight

Traditional government data architecture looks like a pyramid. Data flows up from agencies to a central data warehouse. Analysis happens at the center. Decisions are pushed back down. Every part of that diagram is defensible on its own, and the whole thing collapses under its own weight at scale. By the time data reaches the center it is stale. By the time analysis happens the question has changed. By the time decisions are distributed they are irrelevant. Reuben's queue was not a staffing failure; it was the shape of the architecture expressing itself.

Warehouses are not a mistake. They are a design with conditions, and it is worth being precise about them. A warehouse works well when you have a small, stable set of users, when the questions are predictable, when you have time to centralize the processing, and when you have control over the source systems. Every one of those four conditions is about stability, and each is genuinely achievable inside one program with one mission.

The warehouse fails when the conditions invert: hundreds of teams want data, the questions change daily, access has to be current rather than batched, and the source systems are decentralized and owned by people who do not report to you. Government is the failure case, structurally and permanently. You have federal, state and local agencies, different departments, different priorities and different legal custodians. You cannot centralize everything, and the reason is not that nobody has tried hard enough. Data mesh starts from exactly there: stop trying, let each agency own its data, and make it discoverable and usable by everyone.

Mesh Is an Operating Model, Fabric Is a Technology Layer

Hold this one sentence and most confusion clears. Data mesh is about who owns and serves the data, an organizational and governance model. Data fabric is about how the data is connected and accessed, a technology layer that ties distributed sources together. One is about people and accountability, the other about plumbing and tooling. You can pursue one without the other, but in a large government they work best together. Reuben's warehouse failed because it tried to fix an ownership problem with a storage solution, and no amount of storage has ever produced knowledge about somebody else's data.

Data Mesh: Push Ownership to the People Who Understand the Data

The mesh idea inverts Reuben's model. Instead of one central team owning all data, each domain, whether Transportation, Health or Tax, owns and publishes its own data as a well-tended product for others to use. Four principles define it:

• Domain ownership. The team closest to the data is responsible for its quality, meaning and availability. Transportation owns road-sensor data because only Transportation truly understands it.
• Data as a product. Each domain publishes data with the care of a product: documented, discoverable, reliable, with a named owner and a service-level promise. Not a file dump but a maintained offering.
• Self-serve infrastructure. A central platform team provides shared tools and guardrails so each domain can publish without reinventing security, storage or cataloging. The center enables; it does not gatekeep.
• Federated governance. Common rules on classification, privacy and interoperability standards are agreed centrally and applied everywhere, while day-to-day data decisions stay with the domains.

In a mesh architecture each agency or division is a data domain, and the domain carries four obligations: it owns its data, it publishes that data as a product with clear contracts, it maintains quality standards, and it provides documentation and support. That last obligation is the one most often skipped and the one that determines whether anybody outside the domain will actually use what was published.

The central team's job changes rather than disappears, and this is the part that leaders consistently underestimate. It stops managing all the data and starts doing four different things: establishing the standards for how domains publish, enforcing the governance requirements, maintaining the discovery platform, and supporting cross-domain data products that no single domain owns. For Reuben, this meant his central team became the platform and rules provider rather than the data factory. Domain experts who understood the data finally got to publish it, and the bottleneck dissolved because there was no longer a single queue for it to form in.

Data as a Product Means Contracts, Not File Drops

In a mesh, data is a product, and a product has four things a file drop does not. It has a service level agreement (SLA) stating when it is available and how fresh it is. It has documentation explaining what the data means and what its limitations are. It has a data contract specifying what columns exist, what types they hold and what quality standards apply. And it has a support team, meaning a named group you can call when something is wrong. This is a genuine departure from warehouse thinking, where data is an afterthought of whatever system produced it.

A concrete example makes the discipline obvious. A state health department has disease surveillance data. In a mesh, the health department owns that data, defines the schema, tests data quality, and publishes with a clear contract: "This dataset contains weekly disease reports, updated Tuesdays, with 95% completeness." Another agency that wants to use that data can plan against those terms. It knows the cadence, it knows the day, and it knows in advance that the publisher is not promising complete data, rather than discovering that gap in the middle of a model run.

The DB source says the consuming agency then trusts the contract, and that is worth stating more carefully, because trust is the word that gets architectures into trouble. A contract states what the publisher intends to deliver and gives the consumer a basis for complaint when it does not. It is not evidence that this week's file met the terms. Consumers should verify against the contract rather than assume compliance with it, and publishers should expect that verification and welcome it. A contract plus monitoring is a working arrangement. A contract alone is a well-documented hope, and the completeness figure that stops being true is exactly the kind of failure that surfaces first as a model behaving strangely.

The Self-Serve Platform

Domain ownership only works if publishing is genuinely easy, which is what the self-serve platform exists to make true. Instead of routing everything through a central data team, domains use a shared platform providing five capabilities: a catalog for discovering available data, ingestion for moving data into the mesh, schema management for defining and versioning schemas, quality monitoring for tracking data quality metrics, and access control for managing who can see what.

The platform's defining property is that it abstracts away infrastructure. Domains should not need to know whether data lives in a data lake, a warehouse or a real-time stream, and they certainly should not need to become experts in the storage layer in order to publish a weekly report. If the platform leaks that complexity upward, domains will either not publish at all or will publish badly, and the mesh will exist on the architecture diagram only.

Schema versioning deserves its own attention because it is the boundary where mesh promises meet operational reality. A published schema is a commitment to consumers, and changing it without versioning breaks every downstream user silently. The platform should make the versioned change the easy path and the breaking change the deliberate one. This is the single most valuable guardrail a central team can build, and it costs far less than the incidents it prevents.

Data Fabric: Connect Without Forcing Everything Into One Place

Data fabric attacks the same fragmentation from the technology side. Instead of physically copying all data into one warehouse, a fabric creates a connective layer that lets you find, access and combine data where it already lives. It leans on rich metadata, a smart catalog that knows what data exists, what it means, who can see it and how to reach it, so that a user or an AI model can query across systems without anyone first migrating everything.

Concretely, a data fabric provides four things: a unified query interface across heterogeneous data sources, automatic schema translation, consistent governance and lineage, and caching and performance optimization. Think of it as a translation layer. You are not moving data. You are making it accessible no matter where it lives, which is a fundamentally different engineering problem with a fundamentally different failure mode.

The practical payoff is that a model needing both health data and tax data does not wait for a multi-year migration. The fabric locates both, applies the access policies that have been encoded into it, and serves what those policies permit. Be precise about that last clause. The fabric enforces the rules it has been given, which means an access restriction that exists in a statute, a data use agreement or somebody's head, but has never been expressed as a policy in the fabric, is not enforced by anything. Automatic enforcement is a property of the encoding, not of the architecture, and the gap between what the law requires and what has been encoded is where these platforms get agencies into trouble.

The Semantic Layer

Above the physical data layer of databases and data lakes sits a semantic layer, and it is what makes a cross-boundary query possible at all. It does four jobs. It translates queries, so that "Show me all unemployment claims across all states" becomes a set of queries against each state's system. It manages naming, so that "Applicant ID" in one state and "Client Number" in another resolve to the same concept. It handles quality problems, including missing data, inconsistencies and format differences. And it caches results, so that expensive cross-state queries are not re-run from scratch every time.

The naming problem is the one that looks trivial in a slide and consumes the project. Two states can both be storing an identifier for the same kind of person and mean subtly different things by it: different issuing authority, different uniqueness guarantees, different handling of people who appear twice. Mapping the names is easy. Establishing that the underlying concepts are actually the same is the work, and it is domain work rather than platform work, which is another reason the mesh and the fabric need each other.

Caching carries a governance implication that teams discover late. A cached result is a copy, and a copy of restricted data sitting in a platform layer is subject to the same handling rules as the original. If your fabric caches, the cache is in scope for classification, retention and audit, and it should be designed that way from the start rather than exempted because it feels like infrastructure.

Active Metadata

Traditional metadata is passive. It is documentation that people might read, and in most agencies it is documentation that people demonstrably do not read. Active metadata is different in kind: it is enforced by the system rather than consulted by a human. It carries column lineage, recording where a number came from and what transformed it. It carries data quality rules, such as a column that should have no nulls or a column that should always be positive. And it carries governance policies specifying who can see this data and what transformations are allowed.

When data flows through the fabric, these rules are applied automatically, and that automation is precisely why the metadata has to be treated as a governed artifact in its own right. A wrong lineage record produces a confident and false answer to an audit question. A missing policy produces access that nobody authorised and nobody noticed. Active metadata converts documentation quality into an operational risk, which is a strong argument for maintaining it well and a poor argument for avoiding it, since the alternative is the same risk with no record.

Federation Without Centralization

The key insight is that you do not centralize data, you federate access. Take a federal agency that wants unemployment data from all 50 states, each state running its own system. The fabric knows where each state's data lives. A query arrives asking for unemployment trends. The fabric routes pieces of that query to each state's system. Results come back. The fabric combines them. The user sees one unified view. No data moves permanently, each state keeps its data, and the federal agency gets unified access.

For an agency that legally cannot pool certain datasets in one place, this is decisive, and it is decisive for a specific reason worth naming exactly. Querying in place means you have not created a new consolidated copy in a new location under new custody, which removes one whole category of legal and security problem. It does not, by itself, establish that you were entitled to see the data. Authority to access is a separate question answered by law and by agreement, not by architecture. A fabric can make lawful access practical. It cannot make unlawful access lawful, and any vendor pitch that blurs those two claims should be read very slowly.

Why Government Needs Both Together

Mesh without fabric gives you well-owned data products that are still hard to connect. Fabric without mesh gives you slick connectivity over data nobody is accountable for keeping correct, which is the more dangerous of the two failures because it scales bad data efficiently. Together, domains own and publish trustworthy data products and a fabric makes those products discoverable and queryable across the whole government with governance applied consistently. Reuben's redesign used exactly this pairing: domains became publishers, and a fabric layer wove their products together without a forced central pile.

The ordering follows from that. Because the mesh supplies the accountability the fabric assumes, and because the fabric can only apply governance to products that already have owners, the organizational change has to lead. Agencies that buy the connectivity first almost always end up with a fast route to data that nobody is answerable for, and then spend the following year trying to retrofit ownership onto systems whose owners never agreed to any of it.

The Government Constraints That Shape the Design

Public-sector data sharing is not a free-for-all even with excellent architecture. Three constraints have to be designed in rather than bolted on:

• Purpose limitation. Data collected for one program often cannot be freely reused for another. The fabric must be able to enforce purpose-based access, not only role-based access, which is a materially harder requirement and one many platforms handle poorly.
• Classification and sensitivity tiers. Public, sensitive and restricted data need different handling. Federated governance defines the tiers and the fabric applies them at query time, including for cached results.
• Auditability. When AI uses cross-domain data to make a decision affecting a citizen, you must be able to show what was used, by whom and under what authority. That traceability is what federal accountability expectations rest on, and it is the reason lineage is a governance requirement rather than a nice-to-have.

The governance dimensions a domain must satisfy before it publishes anything are worth listing plainly, because teams tend to remember the first and forget the rest: privacy, covering personally identifiable information and clearance-based restrictions; quality, covering accuracy and completeness; compliance, covering retention and audit trails; and lineage, covering where each element came from. These are why the federated-governance principle is non-negotiable in government. The center sets the rules so that every domain plays by the same privacy and classification standards while still owning its own data.

One caution about the word enforced, which appears constantly in this field. Federated governance means rules set centrally and applied by the platform wherever the platform can see the traffic. It does not reach data a domain shares outside the mesh, exports to a spreadsheet, or hands to a vendor under a separate arrangement. The rules are as good as their coverage, and coverage is an empirical question about your environment rather than a property you get by adopting the pattern.

A Decision Framework for Your Platform

Use this to decide what your agency actually needs before a vendor decides it for you.

There is a fifth answer the table deliberately does not contain, and it is often the right one: neither, yet. The source guidance is that government agencies with three or more divisions managing distinct data should consider data mesh, and that single-agency operations may find simpler architectures entirely sufficient. If your data problem is one team, one warehouse and a handful of analysts, the mesh will cost you more in coordination than it returns in throughput.

A Realistic Maturity Path

Do not attempt a big-bang transformation, which is the warehouse mistake in new clothing. Reuben sequenced it:

1. Set federated governance first. Agree the shared rules on classification, privacy and interoperability before any domain publishes.
2. Stand up self-serve infrastructure. Give domains the tools and guardrails to publish safely.
3. Pilot with two willing domains. Let two departments publish data products and prove the model on real use.
4. Add the fabric layer. Connect the published products with a metadata-driven access layer that applies the governance rules.
5. Scale by adoption, not mandate. Domains join because the platform makes their life easier, not because a memo ordered it.

Choose the pilot domain on evidence rather than on enthusiasm. The transition from centralized to mesh is not overnight, and the reliable starting point is your strongest data domain, meaning the division with the best existing data quality and the clearest mission value in what it holds. Make them the pilot. Once they have published data products successfully, other divisions follow, because the argument stops being architectural and becomes a demonstration they can look at.

Sequencing also protects you from the most expensive ordering error, which is building sophisticated fabric capability before you have anything to connect. Investing in advanced federation before you have ten or more data domains produces an overengineered platform whose maintenance burden exceeds its value. Start with basic federation. Add complexity only when scale actually requires it.

Eighteen months in, Reuben's two pilot domains had published data products that a fabric layer made queryable government-wide, with the purpose limits that had been encoded into the platform applied at query time. The shadow systems started shutting down on their own, because the official path had finally become the easier one. That is the only mechanism that has ever retired a shadow system. Nobody has ever deleted one because a policy told them to.

Anti-Patterns to Avoid

• Mesh without standards. You declare domains and let them publish however they like. No standards, no quality checks, vague descriptions, and nobody trusts the result. Establish non-negotiable publishing standards covering schema format, quality metrics and documentation requirements before the first domain publishes.
• Fabric without governance. You build a federated query system and do not enforce access control, so a user queries sensitive data they should not see. That is a privacy violation delivered at speed. Embed governance in the fabric so that every query is evaluated against access policies before it executes.
• Assuming mesh solves data quality. Domains publish bad data, the mesh faithfully distributes it, and now you have bad data at scale. Mesh makes quality problems more visible rather than fixing them. Use that visibility and make domains accountable for quality.
• Building fabric before you need it. Advanced fabric capability bought before you have ten or more data domains is overengineering, and the maintenance burden will exceed the value. Start with basic federation.
• Treating encoded policy as complete policy. A fabric enforces the rules it has been given. Restrictions that live in a statute, an agreement or an expert's memory and have never been expressed as policy are not enforced by anything, and the platform's confident behaviour will suggest otherwise.
• Treating query in place as legal authority. Not creating a consolidated copy removes one category of risk. It does not establish entitlement to the data. Architecture cannot answer a question that law and agreement answer.
• Consuming a data contract without verifying against it. A contract is a stated intention and a basis for complaint. It is not evidence that this week's delivery met its terms. Monitor against the contract, or the first sign that completeness slipped will be a model behaving oddly.
• Exempting the cache. A cached cross-domain result is a copy of the underlying data and carries the same classification, retention and audit obligations. Designing the cache as pure infrastructure creates restricted data in an ungoverned location.
• Leaking infrastructure into the domains. If publishing requires a domain to understand the storage layer, the self-serve platform has failed and the domains will either not publish or publish badly, leaving you with a mesh that exists only on the diagram.

Practice Prompts

• Data domain mapping. For your agency, identify the natural data domains. Which divisions own data? What data does each division manage? How would each define a data contract for what it holds, including schema, quality metrics and freshness?
• Governance requirements. Write down what governance must be enforced across all domains: privacy, covering personally identifiable information and clearance-based restrictions; quality, covering accuracy and completeness; compliance, covering retention and audit trails; and lineage, covering where each element came from. Then mark which of these your current platform could actually enforce today.
• Federation assessment. Name your biggest cross-agency data challenges. Do you need current data from multiple agencies rather than batched extracts? How much data would actually have to move? What is your tolerance for query latency?
• Contract drafting. Take one dataset your agency already shares informally and write its data contract: columns, types, quality standard, update cadence, availability commitment and named support contact. Note every field you cannot fill in, because each one is a promise you are currently making implicitly.
• Encoded policy audit. List the access restrictions on one sensitive dataset from their actual sources: statute, agreement, internal policy and professional practice. Then check which have been expressed as enforceable policy in your platform. The gap is your real exposure.
• Pilot selection. Rank your divisions by existing data quality and by mission value of the data they hold. The one that scores well on both is your pilot, regardless of who volunteered.

Reflection Questions

• If you could access data from one remote agency as it changes rather than in batches, which agency and which data would matter most to your mission?
• What data quality issues would become visible immediately if you shared your agency's data more openly, and is that visibility the reason you have not?
• What is actually preventing your agency from sharing data more openly with other agencies right now: law, capability, or the absence of anyone whose job it is?
• Who would a consuming agency call if your most-used dataset was wrong on a Tuesday morning, and does that person know they are the answer?
• If an auditor asked which data a specific AI decision used and under what authority, could you produce that record, or would you have to reconstruct it?

Glossary

• Data mesh. An organizational architecture in which data ownership is distributed to source domains, with each domain publishing its data as a product.
• Data fabric. An infrastructure layer providing unified access to distributed data sources through federation, transformation and caching.
• Data domain. A team or agency that owns a specific dataset and is responsible for its quality, documentation and availability.
• Data contract. An explicit agreement about what a dataset contains, including schema, quality metrics, freshness and access requirements. A statement of intent that consumers should verify against.
• Semantic layer. A software layer that translates between different data representations, handling naming normalization, transformation, quality handling and caching.
• Federation. A technical approach to querying multiple data sources without moving the data centrally.
• Active metadata. Metadata enforced by the system rather than merely documented, carrying column lineage, quality rules and governance policies applied automatically as data flows.
• Self-serve data platform. The shared capability set that lets domains publish without a central data team: catalog, ingestion, schema management, quality monitoring and access control.
• Federated governance. Common rules on classification, privacy and interoperability set centrally and applied across domains, effective only to the extent the platform sees the traffic.
• Service level agreement (SLA). The published commitment attached to a data product covering when it is available and how fresh it is.

Related Lessons

• Data Infrastructure for Enterprise AI covers the underlying storage and pipeline decisions this architecture sits on.
• Data Governance for AI develops the federated governance rules that mesh and fabric both depend on.
• Data Quality and AI Performance explains why the quality problems a mesh makes visible matter so much downstream.
• Data Sensitivity and Classification supplies the tiering scheme the fabric applies at query time.
• Data Sharing Agreements for AI covers the agreement layer when data crosses custodial boundaries for model training.
• Designing Agency-Wide AI Platforms places mesh and fabric inside the wider platform strategy.
• AI Interoperability Across Agencies addresses the standards question that cross-domain querying raises.
• Multi-Cloud, Multi-Model Strategy covers the heterogeneity a fabric is asked to hide.
• Shared Services and Infrastructure Models treats the build-or-consume decision for the platform layer itself.

Closing Thoughts

Mesh and fabric are not new ideas, but they are rarely applied in government. The traditional model of centralized warehouses and long request cycles reflects government's traditional organization: hierarchical, centralized, slow. The architecture is not an accident. It is the org chart rendered in storage, which is why an architectural change that does not also change who is accountable produces a new warehouse with better marketing.

If you want a faster, more distributed government, you need faster, more distributed data architecture, and you need to be honest that this is an organizational change carrying a technical one rather than the reverse. Reuben's three wasted years were not spent on the wrong technology. They were spent on the right technology pointed at the wrong problem, by a team that had been made responsible for knowledge it could not possibly hold.

Key Takeaways

• Mesh is an operating model; fabric is a technology layer. One changes who owns and serves data; the other changes how distributed data is connected and accessed. Confusing them is how agencies buy a tool to solve an accountability problem.
• The warehouse is a design with conditions, and government inverts all of them. Warehouses suit stable users, predictable questions, time to centralize and control of sources. Government has hundreds of teams, daily-changing questions, current-data needs and decentralized custodians.
• Data mesh pushes ownership to the domains. The team closest to the data owns it, publishes it as a product with contracts, maintains quality and provides support, using self-serve tools and federated rules from the center.
• The central team's job changes rather than disappearing. It sets publishing standards, enforces governance, maintains the discovery platform and supports cross-domain products no single domain owns.
• A data product carries an SLA, documentation, a data contract and a support team. A contract states intent and gives consumers a basis for complaint. Verify against it; a contract without monitoring is a well-documented hope.
• Data fabric connects without forced migration. A metadata-driven layer queries data where it lives, using a semantic layer for naming and translation and active metadata for lineage, quality rules and policy.
• Automatic enforcement is a property of the encoding, not of the architecture. A restriction that lives only in a statute, an agreement or an expert's head is not enforced by the fabric, however confidently the platform behaves.
• Query in place is not legal authority. Avoiding a consolidated copy removes one category of risk. Entitlement to the data remains a question for law and agreement.
• Cached results are copies. Classification, retention and audit obligations follow the data into the cache, and designing the cache as exempt infrastructure creates restricted data in an ungoverned place.
• Government needs both, with compliance designed in. Purpose limitation enforced at query time rather than by role alone, classification tiers applied consistently, and auditability sufficient to show what was used, by whom and under what authority.
• Sequence it and scale by adoption. Governance, then self-serve tooling, then a pilot with your strongest domain, then the fabric, then growth because the official path became the easier one. Never a big-bang mandate.
• Do not build fabric before you have domains to connect. Advanced federation before ten or more data domains is overengineering, and agencies with fewer than three divisions holding distinct data may not need a mesh at all.

Frequently Asked Questions

Is data mesh a replacement for our data warehouse?

No, and framing it that way tends to produce a migration project that misses the point. A warehouse is a perfectly good design when its conditions hold: stable users, predictable questions, time to centralize and control over the sources. Many domains will keep a warehouse internally and publish products from it. What mesh replaces is the assumption that one central team can own and understand all of an organization's data, which is the assumption that failed for Reuben. The storage is not the problem; the ownership model is.

How small is too small for a data mesh?

The source guidance is that agencies with three or more divisions managing genuinely distinct data should consider a mesh, while single-agency operations may find simpler architectures sufficient. The underlying test is whether any central team could plausibly hold real knowledge of every dataset. If one team can genuinely understand all of it, distributing ownership adds coordination cost without removing a bottleneck, because there is no bottleneck to remove.

Does a data fabric let us share data we currently cannot share legally?

No. This is the most consequential misunderstanding in this space and the one most often encouraged by product marketing. Querying data in place means you have not created a new consolidated copy under new custody, which genuinely removes a category of legal and security problem. It does not create authority to access data you were not entitled to see. Authority comes from statute and from agreement, and a fabric can only make lawful access practical. Where sharing requires a legal instrument, build the instrument; Data Sharing Agreements for AI covers that work.

Who pays for the self-serve platform?

Whoever funds it will be tempted to control it, which is the tension to manage. The platform is a central investment whose entire value proposition is that it enables rather than gatekeeps, so the funding arrangement should not recreate the queue by making domains request access to the central team's time. Fund the platform team to build capability and guardrails, and measure them on how many domains publish successfully without their involvement rather than on how much they publish themselves.

What if a domain refuses to participate?

Then the platform is not yet easier than their alternative, and that is diagnostic information rather than a compliance problem. Reuben's shadow systems shut down when the official path became the easier one, not when a memo ordered it. Before escalating, find out what the holdout domain would have to do to publish and how long it would take them. If the honest answer is weeks of work in an unfamiliar tool, the refusal is rational and the fix is on your side of the line.

How do we handle a domain that publishes poor quality data?

Visibly and by contract rather than by exception. A mesh does not fix quality; it makes quality legible, which is the actual value. Publish the quality metrics alongside the data so consumers can see the completeness figure, hold the domain to the contract it wrote, and escalate through the governance structure rather than by having the central team quietly clean the data. Every time the center repairs a domain's data silently, it takes back the accountability the mesh was built to distribute.

Does the fabric slow queries down?

Federated queries across heterogeneous systems are generally slower than reading a single local table, which is why caching and performance optimization are listed as core fabric capabilities rather than as refinements. The right question is not whether federation is slower than a warehouse read but whether it is fast enough for the decision being made, against the alternative of waiting months for a migration that may never complete. Establish your latency tolerance per use case first; it is usually looser than people assume for analysis and tighter than they assume for anything operational.