Yesterday's Top Launches: 2 Tools from September 2, 2026
A data engineer shares an unsponsored, hands-on account of adopting and living with the DataFabric active metadata platform in a mid-sized analytics team, where the focus has shifted from table loading speed to data discoverability, trust, and downstream impact.
When data teams hit a certain size, the conversation changes. It stops being about how fast we can load a table and starts being about whether anyone can find that table, trust it, and know what breaks downstream when it changes. The product category that answers those questions, the data catalog, has gone from a nice-to-have to a serious line item. DataFabric, an active metadata platform built by former Snowflake and Google engineers, sits firmly in that space. Over the past several weeks I’ve been running it inside a mid-sized analytics organization, and I want to share what it actually feels like to adopt, configure, and live with.
This is not a sponsored post and I have no affiliation with the vendor. I’m writing this because metadata management keeps getting oversimplified by vendors and overcomplicated by consultants. The reality is somewhere in the middle, and I think there’s value in describing it from the operator’s side of the console.
What DataFabric is and isn’t
DataFabric is often pitched as a data catalog, but that undersells it. It is really an active metadata platform. The “active” part means it doesn’t just store descriptions of your tables. It observes your systems, extracts usage signals, builds lineage graphs, and feeds governance workflows.
Before we dive into features, let’s separate the term from the product. Data Fabric as a concept has been around since the late 2010s. It started as an enterprise architecture idea, something Gartner talked about in terms of connecting distributed data assets across hybrid environments. Then the term got absorbed by marketing teams and applied to everything from data virtualization to semantic layers. That has created a lot of confusion. When I say DataFabric here, I mean the metadata platform product, not the architectural vision.
The product connects to your data warehouse, your orchestration tool, and your BI layer. It pulls catalogs, parses query logs, profiles data, and reconstructs the journey of a dataset from ingestion to dashboard. In doing so it creates a living map that answers questions like “what will break if I change this column?” better than any spreadsheet ever could.
Where it fits in a modern stack
Most analytics engineering teams run on a few core tools. The actual compute might sit in Snowflake or BigQuery, transformation happens in dbt, orchestration happens through Airflow or Dagster, and dashboards live in Looker or Tableau. None of these tools were designed to be the system of record for everything.
That is the gap DataFabric fills. It sits on top of these systems rather than replacing them. You connect it to your warehouse and your orchestrator, and it becomes the shared layer that understands what lives where and how it all fits together.
The infrastructure is intentionally main-stream. It runs as a containerized service and ships with a REST API, an event bus, and a web UI. Integration is mostly read-only from the perspective of your data systems. It uses a bot account with SELECT privileges to inspect your warehouse, and it hooks into your orchestration tool through webhooks or a service account to observe run events. You do not need to re-architect anything to get started, which is rare for this category.
Setting up the connection
Day one is deceptively simple. You create a connection to your warehouse, give DataFabric read-only access, and wait for it to discover tables. In my case, connecting it to a Snowflake account took roughly twenty minutes of configuration work, most of which was spent creating the right service account and making sure it was locked down to the appropriate schemas.
What arrives after that initial scan is what separates a serious metadata tool from a toy. The platform crawls through your schemas, pulls column definitions and data types, infers primary and foreign key relationships where it can, and starts building a baseline inventory. That baseline is useful, but it’s also shallow. The real value starts appearing once the platform has observed enough activity to understand how data is used.
A natural instinct is to enrich everything right away, to write descriptions for every table and every column. Resist that urge. You will burn weeks completing documentation for tables nobody will ever query again. Let the usage data accumulate first. After a week or two, you will know which tables matter, because the platform will rank them by query activity, and those are the ones worth describing in detail.
Column-level lineage the way it should work
Lineage is the feature that makes data engineers go quiet in a good way. DataFabric claims column-level lineage, and after testing it, I can confirm the claim holds up in practice. The platform reconstructs how data flows from source tables into transformed