Why Data Extensions Become Unmanageable in Large SFMC Orgs

‍

Every large Salesforce Marketing Cloud org has that one folder nobody opens anymore.

It holds a few hundred data extensions with names like DE_Reactivation_v3_FINAL, and no one currently on the team remembers who built them or whether anything still writes to them.

‍

This is not a failure of discipline. It is what happens when a flexible data model meets five years of campaigns, three team reorganisations, and a platform that never forces you to clean up.

Data extensions are deliberately unopinionated. That is their strength when you start and their weakness at scale.

‍

This post looks at the specific mechanics that turn a tidy data model into an unmanageable one, and what actually helps.

‍

The platform never asks you to clean up

‍

Retention is opt-in, not default

Records in a data extension are retained indefinitely unless a data retention policy is applied. Nothing expires on its own.

Salesforce recommends choosing a retention policy at creation time, precisely because retrofitting one later is harder.

‍

You can still apply a policy from Contact Builder to a data extension holding fewer than 100 million records, and row-based or object-based retention windows can be adjusted after creation as long as the table stays under one billion records.

Those ceilings sound generous. In practice they mean a neglected table can grow for years before the platform gives you any signal at all.

‍

Nothing marks a table as abandoned

There is no built-in "last read" timestamp on a data extension. A table that no automation has touched in two years looks identical to one powering tomorrow's send.

‍

So teams default to the safest behaviour: leave it. Deleting something that might be referenced by a journey nobody has audited is a career risk, and keeping it costs nothing visible.

Multiply that decision across every marketer who has ever passed through the org.

‍

Naming conventions decay faster than anything else

‍

Consistency has to be agreed before the first table

Salesforce's own guidance is blunt about this: agree a standard naming convention across platforms early, down to whether a field is Email Address, Email, or EmailAddress.

‍

That advice is easy to follow on day one and nearly impossible to enforce on day four hundred.

New agencies arrive with their own conventions. A regional team spins up its own business unit. Someone builds a quick table for a one-off send and it becomes load-bearing.

‍

Field names are the real cost

Table names are annoying when inconsistent. Field names are expensive.

‍

If SubscriberKey is the join key in one table and ContactID in another, every query written against both has to encode that knowledge. The knowledge lives in the heads of whoever wrote the query, and it leaves when they do.

‍

The data model spreads across places that do not talk to each other

‍

Contact Builder holds one version of the truth

Attribute groups in Contact Builder are effectively mini data models: attribute sets grouped together with defined relationships to the contact record.

‍

The recommended pattern is to link a data extension to the contact record first, then link other relevant extensions to the contact record or to each other for more complex structures. Relationships are defined as cardinalities: one-to-one, population, one-to-many, and many-to-many.

‍

Your queries hold another

The catch is that a query activity does not have to respect any of it. SQL in Automation Studio will happily join two tables that Contact Builder says are unrelated.

‍

So the org ends up with a documented model in Contact Builder and an actual model encoded across hundreds of query activities. Populations are not sendable on their own, which pushes teams toward yet more intermediate tables to get data into a sendable shape.

‍

Each intermediate table is reasonable in isolation. Together they are the sprawl.

‍

Size quietly becomes a performance problem

‍

Query activities time out, imports do not

Query activities have a timeout, and the size, structure, and number of data extensions all affect how they perform. Salesforce explicitly recommends staying within the documented ranges to keep queries healthy.

‍

This creates an unpleasant asymmetry. Importing more data is always easy. Reading it back gets slower and slower until a query that ran fine for two years starts failing at 3am.

‍

Some limits are hard walls

Synchronized data extensions cap at 250 fields. Retention policy application has its own record thresholds.

‍

Teams usually discover these limits at the worst moment: mid-build, under a campaign deadline, when the workaround is to create yet another table.

‍

Why the usual fixes do not hold

‍

Documentation goes stale immediately

The standard response is a spreadsheet listing every data extension, its owner, and its purpose.

‍

It is accurate for about a month. Nothing in SFMC updates it, so it drifts from reality until people stop trusting it, and an untrusted inventory is worse than none because it produces confident wrong answers.

‍

Cleanup projects have no natural owner

Auditing a thousand tables is weeks of work with no campaign attached to it. It gets scheduled, deprioritised, and rescheduled.

‍

The teams that do succeed usually change the inputs rather than the outputs: fewer people writing ad hoc SQL, fewer one-off tables created under deadline pressure, and a smaller set of well-understood sources that everything else builds from.

‍

What actually reduces the sprawl

‍

Set retention at creation, always

The single highest-leverage habit is applying a retention policy when the table is created, not when it becomes a problem.

‍

Working tables built by a query should almost never retain data indefinitely. If the query rebuilds the audience each run, the previous run's rows are dead weight.

‍

Cut the number of tables people need to create

Most intermediate data extensions exist because someone needed a place to park a segment while they figured out the join.

‍

The fewer people who need to hand-write SQL against _Sent, _Open, and _Click to build a routine audience, the fewer of these tables appear. That is the part of the problem worth attacking, because it is upstream of everything else.

‍

Fixing the model after the fact is archaeology. Reducing what gets created is maintenance.

‍

Make exploration cheap again

A lot of table sprawl is really failed exploration left on disk. Someone wanted to know how many contacts opened in the last ninety days but not in the last thirty, and building that answer required a place to put it.

‍

A marketer who can describe an audience in plain language does not need a scratch table to test an idea.

‍

QAiry generates the SQL against your existing data views and data extensions, so the exploration happens in a query rather than in a new object nobody will ever delete. The tables that do get created are the ones that were actually needed, and the ones that were only ever a question stay questions.

‍

See QAiry in action

‍

If your org has more data extensions than anyone can name, the fastest way to stop the growth is to reduce how many people need to build one just to answer a question. The backlog will still be there, but it stops getting bigger while you work through it.

You can see how QAiry builds audiences against a real SFMC data model at qairy.com/product-demos, or try it against your own org at qairy.com/try-it-free.