Data silos are not simply data living in multiple systems — they are separations that block a legitimate use. Three distinct types exist: technical (storage not connected), organisational (access controlled by one team), and semantic (same term means different things in different places). Most silos originate from defensible decisions like acquisitions, compliance requirements, or teams shipping fast. Some silos should deliberately remain, particularly those required by regulation or those that limit breach blast radius. The recommended fix is to centralise context rather than data: inventory what exists, agree written definitions for reported terms, make metadata searchable, and only then move data for uses still blocked. Semantic silos — where two teams produce different numbers from the same warehouse using different but valid definitions — cannot be fixed by any pipeline or migration, only by a business glossary with owned definitions attached at the point of use.
Table of contents
Key TakeawaysWhat a Data Silo Actually IsThe Three Kinds of Data SiloWhy Data Silos FormWhich Silos to Break and Which to LeaveWhat Data Silos Actually CostHow to Break Down a Data Silo, In OrderSemantic Silos: The Kind No Pipeline Can FixFour Ways Silo Projects FailWhere Decube FitsFrequently Asked QuestionsQuestions this post answers
What is the difference between a technical, organisational, and semantic data silo?
Technical silos separate storage — data sits in systems that don't connect. Organisational silos separate access — data is reachable but one team controls who can use it. Semantic silos separate meaning — the same term describes different things in different places, so two correct reports disagree. Each requires a different fix: tooling for technical, governance decisions for organisational, and a business glossary for semantic. No pipeline work touches semantic silos. Teams untangling cross-team data disagreements track the latest thinking on data governance on daily.dev.
Does moving data into a data warehouse fix data silos?
A data warehouse fixes only technical silos. It does nothing about a team controlling access, and it actively hides semantic silos by placing two conflicting definitions of the same term in the same location — where the disagreement then looks like a data quality problem rather than a definitions problem. Definitions must be agreed before or alongside any consolidation effort, not after. Developers and data engineers debating warehouse-first vs. metadata-first strategies find relevant discussions on daily.dev.
How do I decide which data silos to break down and which to leave in place?
Run each silo through four questions in order: Is separation required by a regulator, contract, or residency rule? Would merging widen the blast radius of a breach? Is there a named person today whose work is blocked? Does it produce conflicting versions of a reported number? The first 'yes' decides the outcome. Regulated or security-boundary silos should stay; only publish their metadata. Break silos only when a named person is blocked from a named use. Data platform teams navigating governance trade-offs like these share approaches on daily.dev.