What MyDataWork holds about your estate, what it never holds, and why structure answers the questions your data can’t.
“We only read metadata” reads as either reassuring or limiting, depending on where you stand. It’s good news if you’re trying to adopt something new without waiting weeks to clear a security review. It can sound like bad news if “only metadata” makes you anticipate a thinner product than desired.
For the questions MyDataWork exists to answer, that second worry is misplaced. Metadata isn’t a reduced version of reading your files. It’s the right material at the right grain of detail, and reading the files wouldn’t answer those questions any better. But “metadata” is a word people use to mean wildly different things, so it’s worth being concrete about what we hold, what we do with it, and why the distinction matters more than it first appears.
A 2:50 walkthrough of what we read and what we don’t. The folder scan is a real connector run, not a mockup.
What we actually hold
For a warehouse table, metadata means the table exists, what it’s called, where it lives,
that it has a column named order_date of type DATE and one named region
of type VARCHAR, when it last changed, and what the analyst wrote in the column comment.
What we don’t hold is any of the dates in that column, or any of the regions. Not one row. Not a sample, not a summary, not a count of distinct values.
What we hold
Names, types, structure, relationships, when it changed, what people wrote about it.
What we never hold
Values, rows, query results, file contents, anything a person typed into a cell.
One nuance you’ll notice if you install our desktop connector: for local files, that connector opens the file on your own machine to read its structure, meaning sheet names, column headers, and the tables a query references. It sends us that structure and nothing else. The service never receives your file. We say “we never receive or store your contents” rather than “we never open a file,” because the second one wouldn’t be true.
The part nobody explains: making it comparable
Here is the problem with collecting metadata from sixteen tools. Every one of them describes itself in its own dialect, and none of them agree.
| Databricks | name: “order_date” | type_text: “date” |
| Power BI | name: “Order Date” | dataType: “dateTime” |
| ThoughtSpot | name: “Order Date” | data_type: “DATE” |
| Sigma | label: “Order Date” | type: { “kind”: “date” } |
| Looker | name: “orders.created_date” | type: “date” |
| Spreadsheet | { “Orders”: [“order_date”, “region”] } | |
Six sources, six shapes. One calls the name label. One nests the type inside an
object. One qualifies every field with its view. One is a dictionary keyed by worksheet. If you
store what each tool hands you, you have six incompatible piles and nothing that can be compared
across them.
Once a Snowflake table, a Power BI dataset, an Alteryx workflow, and somebody’s spreadsheet are described in the same terms, they can be reasoned about together, and that is what every feature in the app is standing on in the spirit of helping data workers be both more productive and participative in their organization’s success.
What normalization buys
- Lineage across tools. A Tableau workbook and a dbt model both reference
analytics.sales.orders. They said it differently; normalized, they resolve to the same table, so the dependency between them is visible without anyone drawing it. - Change impact. “What breaks if I drop this column?” is only answerable if columns from every tool are described the same way.
- Use-case alignment. Matching the work to the business question it serves depends on comparing assets that came from unrelated systems.
- External-data readiness. Deciding whether a public dataset can join to your work needs one question answered across the whole estate: is there a date, and is there a place?
Why structure is the right material, not a compromise
The strongest argument for metadata isn’t privacy. It’s that the questions this product asks are structural questions, and values don’t answer them.
Consider what people actually ask about their estate:
- Which reports break if I drop this column? Answered by structure and dependency. Reading a billion rows tells you nothing about it.
- Who else is already doing this analysis? Answered by names, topics, and relationships. The contents of two similar files don’t tell you the teams are duplicating work. The shape of the work does.
- Can this public dataset join to my forecast? Answered by whether a date column and a region column exist. Not by what’s in them.
For all three questions, contents are not a richer input. They’re an irrelevant one. Reading them would mean taking on every ounce of the risk for none of the answer.
Three more reasons structure is the better material
- It stays true longer. Values change hourly; structure changes rarely. An analysis built on what a table is holds up for months. One built on what it contained last Tuesday was stale before you read it.
- It fits in one picture. Structure is small. The entire shape of a large estate can be held together and reasoned across at once, every asset and every dependency, in one graph. You cannot do that with contents, at any price.
- It is the only thing that’s comparable. Comparing the contents of a spreadsheet with the contents of a warehouse table is meaningless. Comparing their structures is exactly how you discover they’re the same work done twice.
The critic’s POV: every source gives you something different
True, and we don’t hide it. A warehouse publishes column types and the analyst’s own comments. A CSV declares column names and, by the nature of the format, no types at all. Inferring them would mean reading the data, which we won’t do. Some tools publish a great deal; a few publish very little.
So the app tells you, per source, what it holds and what that source is capable of publishing. Where a tool doesn’t expose something, it says so plainly rather than leaving a blank you have to interpret. A CSV having no declared types is a fact about CSVs, not a gap in your catalog.
Uneven inputs still produce comparable outputs, because normalization happens after collection. A spreadsheet contributes less than a Snowflake table, and both still land in the same graph and answer the same questions about your estate.
What this adds up to
You get a picture of your data work: what exists, who depends on it, what it’s worth, and how it connects, assembled from the parts of your systems that were designed to be read. No agent inspecting your rows. No copy of your data in someone else’s cloud. No new place for a breach to matter.
And the reason we can say that without hedging is not restraint. It’s that we never needed your data to answer the questions in the first place.
See what it holds about your own estate
Load the demo workspace, or connect a source and look at Setup → Metadata. It shows exactly what we hold, where each piece came from, and how fresh it is. Free for 90 days, no card.
See the plans →