[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-data-mesh::en":3,"gloss-cluster-data-mesh::en":26,"gloss-next-data-mesh::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"data-mesh","data-infra","Data Mesh","Data mesh is an approach to analytical data architecture that moves ownership of data from a single central team to the domain teams that generate it, and asks each of those teams to publish its data as a product with a documented interface, a named owner and a service level. It is primarily an organisational design; the technology underneath is mostly the same warehouses, lakes and pipelines used in centralised setups. The problem it responds to is a specific failure mode of the central data team. As a company grows, that team becomes a bottleneck: it owns pipelines for domains it does not understand, its backlog grows faster than its headcount, and when a source system changes nobody tells it, because the producing team does not know the pipeline exists. Quality suffers in a way that is structural rather than a matter of effort — the people who understand the data are not the people responsible for it. A mesh has four commonly cited principles: domain ownership of data, data served as a product, self-serve infrastructure, and federated governance. In practice the second and third do most of the work. Treating data as a product means the payments team publishes a payments dataset with a schema contract, discoverability metadata, quality expectations and someone accountable when it breaks — the same obligations a team would accept for an API. Self-serve infrastructure means a central platform group still exists, but builds the paved road rather than the pipelines: storage, orchestration, cataloguing, access control and monitoring that domain teams use without needing platform work for each new dataset. Federated governance keeps the cross-cutting rules — privacy classifications, retention, naming, interoperability — global while leaving the content local. Mesh is not a default. It carries real overhead and assumes domain teams have the engineering capacity and the appetite to run data products, which is often untrue below a certain size; a well-run central team is usually the better answer for a smaller company. Practical note: adopt it incrementally by making one high-traffic dataset a proper product first — contract, owner, SLA, documentation — and see whether the producing team can sustain it before restructuring anything.","Data mesh is an organisational approach that assigns data ownership to the domain teams that produce it, treating datasets as products with published contracts.",null,[11,14,17,20,23],{"slug":12,"name":13},"data-catalog","Data Catalog",{"slug":15,"name":16},"data-contract","Data Contract",{"slug":18,"name":19},"data-lake","Data Lake",{"slug":21,"name":22},"data-lineage","Data Lineage",{"slug":24,"name":25},"semantic-layer","Semantic Layer",[27,31,34,37,40,44,47,50,53,56,60,63],{"slug":28,"category":5,"name":29,"updated_at":30},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"ann-search","ANN Search",{"slug":35,"category":5,"name":36,"updated_at":30},"backpressure","Backpressure",{"slug":38,"category":5,"name":39,"updated_at":30},"batch-processing","Batch Processing",{"slug":41,"category":5,"name":42,"updated_at":43},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":45,"category":5,"name":46,"updated_at":30},"cache","Cache",{"slug":48,"category":5,"name":49,"updated_at":30},"cap-theorem","CAP Theorem",{"slug":51,"category":5,"name":52,"updated_at":30},"change-data-capture","Change Data Capture (CDC)",{"slug":54,"category":5,"name":55,"updated_at":30},"chroma","Chroma",{"slug":57,"category":5,"name":58,"updated_at":59},"chunk-overlap","Chunk Overlap","2026-08-24T03:30:02+00:00",{"slug":61,"category":5,"name":62,"updated_at":30},"columnar-storage","Columnar Storage",{"slug":64,"category":5,"name":65,"updated_at":30},"connection-pooling","Connection Pooling"]