---
title: "MDLH: Cut waste with orphan asset detection"
url: "https://atlan.com/demos/mdlh-cut-waste-with-orphan-asset-detection/"
excerpt: "Identify every orphaned table burning storage and compute — ranked by priority and ready to act on immediately."
description: "Replace the uncomfortable guesswork of platform cost reviews with a prioritized cleanup list driven by evidence. Query every asset without lineage, see ownership and activity data alongside each one, and follow a complete workflow from identification through deprecation and Jira-tracked removal. Stop paying for tables nobody queries, nobody owns, and nobody tracks — and do it confidently, not by gut feel."
format: "Video"
duration: "PT4M35S"
video: "https://videos.ctfassets.net/nwa1c00rtgxb/62UHqZtMK71N2wPSnRlseZ/9a769e05b9fa7ea940ce6c09f4aea5a8/MDLH_-_Cut_waste_with_orphan_asset_detection.mp4"
thumbnail: "https://images.ctfassets.net/nwa1c00rtgxb/5uXElrZ6RkQCqqNOGJoZwU/0cd3587ef871b4ba86521b8d1956ba33/mdlh-cut-waste-with-orphan-asset-detection.webp"
content_purpose: ["Product Overview"]
target_persona: ["General", "Data Analyst", "Data Engineer", "IT Administrator"]
journey_stage: ["S2 - Discovery", "S3 - Solution Design", "S4 - Business Case", "C1 - Onboarding", "C2 - First Value", "C3 - Adoption"]
use_case_context: ["Training"]
product: ["Enterprise Data Graph - Data Lineage"]
published: "2026-03-13"
updated: "2026-06-02"
content_type: "video transcript"
transcript_source: "sheet"
---

# MDLH: Cut waste with orphan asset detection

Transcript of the video at https://atlan.com/demos/mdlh-cut-waste-with-orphan-asset-detection/

Your platform has tables nobody queries, nobody owns, and nobody tracks. They're burning storage and compute every day. One query gives you the full list — ranked and ready to act on. Every platform review has the same uncomfortable moment: the bill. Storage costs, compute costs — and nobody can confidently say which tables are actually still needed. You can't deprecate what you can't identify. This query gives you the list. We’ve all tried to figure out which tables in our data platform are actually being used, and we all know the problem. We can check one asset at a time in the lineage view, but when we’re managing thousands of assets across multiple connectors, that approach doesn't scale.

We need to see the full picture at once. The Metadata Lakehouse gives us a queryable view across our entire asset catalog. In this walkthrough, we'll run a single SQL query to surface every asset without lineage — with cleanup recommendations built in — then take it all the way through to deprecating an asset and creating a tracked Jira ticket. Before we go to the Lakehouse, let’s take a look at what we can do with in the Atlan UI. If we open any table and go to the Lineage tab, we can see its upstream sources and downstream consumers.

This is great for understanding one asset in context. The limitation is exactly what it sounds like — it's one asset at a time. The moment we want to ask "which of my 3,000 tables have no lineage at all and what should I do about them," the UI isn't the right tool. That's where the Metadata Lakehouse comes in. So let’s run the query that surfaces all of it at once. In our SQL editor we can build a query to surface every asset without lineage. The query filters for tables, views, and materialized views with no recorded lineage connections, and excludes anything updated in the last 90 days.

That threshold matters — we don't want to flag assets that were just created and simply haven't been connected yet. This query has a built-in cleanup recommendation column that categorizes each asset into one of three priorities. We run the query and get results. As we look at the results, we can see these cleanup recommendations. Red means it's already marked for deprecation in Atlan; it’s safe to delete. Yellow means no activity in six-plus months, so it’s worth reviewing for removal. Green means it's recently created or may be intentionally standalone. It also returns the asset name, type, connector, owner, and the number of days since the last update.

Here's what makes this query valuable beyond just a list. It combines lineage status with ownership data, certification status, and activity recency — so instead of getting a raw list of 200 orphaned tables, we're getting a prioritized action list. On top of that, we have the people we should reach out to if needed, no asking on Slack who cares about the table. That's the difference between a data dump and something we can actually work from. Now let’s pick the right candidate to act on first. With these results, we can start identifying the right assets for depreciation.

We can sort by time since last update, descending, and look for assets in the yellow category — no activity in six months or more, no owner. These are our best candidates for immediate action. Now let's complete the workflow — starting with the deprecation step in Atlan. Note the asset name and the owner field. Even if the owner field is empty, we know the next steps: we'll need to investigate at the team level. Once we have investigated with the table owners or the team and are confident, we can deprecate one of these candidates.

Now let's complete the workflow — starting with the deprecation step in Atlan. In order to deprecate the assets, we need to ensure that we notify anyone that may be using these assets of the impending deprecation, and also kick off our technical deprecation process through the creation of a Jira ticket. All of this can be done inside of Atlan. We take the GUID from the query results and open it in Atlan. In the asset profile, we go to the Overview section and update the Certificate Status to Deprecated and enter that we are actively working to deprecate the asset on a specific date and to reach out if there are issues with this.

It serves as a double signal — a warning to stop building on that asset, and a confirmation to anyone who finds it that it's already been reviewed and marked for retirement. One last step to close the loop. From the asset profile, we create a linked Jira ticket directly. Linking the ticket to the asset provides traceability — anyone who looks at this asset in the future can see not just that it's deprecated, but that there's an active work item tracking its removal. And with that, the full workflow is complete. We now have a workflow that takes we from "I don't know what's orphaned" to a prioritized cleanup list, a deprecated asset, a tracked Jira ticket, and the visibility given to our entire company of it— all driven by a single SQL query.

If we want to export all the metadata from our data estate, including lineage, to feed into an AI agent or provide context to other systems, that walkthrough is linked below. [END YT CTA]