Database property evolution

Database property evolution is the tracking of how the properties, fields, and attributes attached to records in a database change over time, including additions, deprecations, and shifts in fill rate. A property is a single field on a record, such as job title, lifecycle stage, or last activity date. Evolution is the running story of which properties get added, which fall out of use, and how completely each one is populated as the database matures.

It matters because a data model is never finished. Teams add fields for a campaign, a new segment, or a one-off report, and most of those fields are never cleaned up. Over a year or two a record can carry dozens of properties, many of them empty, stale, or duplicated. Property evolution makes that drift visible, so the schema stays a deliberate structure rather than an accumulation of good intentions.

Unlike a record-count metric, property evolution is mostly about quality and structure rather than volume. A database can hold the right number of records and still be hard to work with because the properties that describe them are inconsistent. Tracking evolution keeps the model aligned with how teams actually segment, target, and report.

Database property evolution does not reduce to one equation, because it tracks several dimensions of change at once. Instead of a single rate, you measure a small set of signals per property and watch how they move across periods. Together they tell you whether the schema is improving or decaying.

Measure each property against these signals to build the picture.

1. 1

   Fill rate

   The share of records that have a non-empty value for the property. A field that drops from 80 per cent to 30 per cent filled is decaying, even if no one removed it.

2. 2

   Freshness

   How recently the property was last updated across the base. Stale freshness on a field like last activity date means the data behind it has stopped flowing.

3. 3

   Property count and churn

   The number of active properties and how many are added or deprecated each period. Rising count with flat usage signals accumulating clutter.

4. 4

   Usage in workflows

   Whether the property is referenced in segments, automations, or reports. A field used nowhere is a candidate for deprecation regardless of how full it looks.

Database property evolution looks like a single qualitative idea, but it resolves cleanly into measurable drivers, which makes it well suited to a metric tree. Schema health is the product of how completely properties are filled, how fresh they stay, and how tightly the property set maps to real usage. Each of those has a different owner and a different failure mode.

The decomposition below separates completeness, freshness, and structure so a decline in schema quality can be traced to its source. If reports start returning gaps, the tree shows whether a key field stopped populating, an integration went stale, or the property set has simply grown faster than anyone is maintaining it.

There is no single target for property evolution, but each underlying signal has a usable range. The benchmarks below describe what healthy looks like for the dimensions you track per property. They are most useful applied to core fields the business depends on, rather than every field that exists.

Improving property evolution means keeping the schema lean, full, and current as the database grows. The gains come from governing what gets added, automating how fields stay populated, and retiring properties that have stopped earning their place. These four practices move it the most.

1. 1

   Treating field count as progress

   More properties is not better data. A growing field list with flat usage is clutter accumulating, so judge the schema on fill and use, not on size.

2. 2

   Adding fields without owners

   A property with no owner has no one accountable for keeping it filled. Unowned fields decay first, so assign ownership at creation, not after the field has gone stale.

3. 3

   Ignoring freshness

   A field that is fully populated but never updated looks healthy and is quietly wrong. Track last-updated recency alongside fill rate so stale data does not pass as complete.

4. 4

   Never deprecating anything

   Schemas that only grow eventually become unworkable. Build a regular retirement step so unused properties leave the model instead of lingering forever.