The High Structural Cost of Generic Relationship Graphs

Why flexibility often becomes the most expensive feature in a data model.

In a previous article, we explored how mature analytics platforms eventually establish Canonical Business Models.

The goal was not simply cleaner reporting.

The goal was control.

Control over business definitions.

Control over transformations.

Control over how information moves through the system.

But once teams begin building their own data models, a new temptation appears.

A seductive one.

Instead of explicitly modeling the business, why not create a structure capable of modeling everything?

The Dream of Infinite Flexibility

Imagine you are designing a new platform.

You know requirements will change.

You know users will request custom fields.

You know new entities will emerge.

You know today's schema will eventually become obsolete.

The obvious solution seems attractive:

Don't define entities at all.

Define relationships.

Define attributes.

Define metadata.

Create a generic framework capable of representing anything.

Many architectures arrive at some variation of:

Entity
Attribute
Value

or

Node
Relationship
Node

The promise is compelling.

Future-proofing.

Unlimited extensibility.

Maximum flexibility.

The business changes.

The schema does not.

At least in theory.

Why Engineers Fall In Love With It

Generic models solve a real problem.

Imagine a project platform.

Today a project contains:

• Name
• Status
• Budget

Tomorrow somebody requests:

• Region
• Risk Score
• Sustainability Rating

A traditional relational model requires schema changes.

A generic model simply stores new attributes.

No migration.

No redesign.

No deployment.

The platform adapts instantly.

This feels powerful.

And in the early stages of a product, it often is.

The flexibility is real.

The cost simply hasn't arrived yet.

The Missing Question

Most teams ask:

How easily can we store this data?

Far fewer ask:

How easily can we retrieve this data?

Those are not the same problem.

Databases spend far more time answering questions than storing information.

Particularly analytical systems.

And this is where generic models begin charging interest on their flexibility.

The Query That Reveals Everything

Suppose an executive asks:

Which projects in Europe with budgets above $5 million experienced schedule slippage while maintaining high issue density?

In an entity-centric model, the query is relatively straightforward.

The database understands:

• Projects
• Budgets
• Regions
• Schedules
• Issues

Those concepts exist explicitly.

Indexes can be built around them.

Statistics can be collected.

Query planners can optimize access paths.

The database understands the shape of the problem.

Now imagine the same request against a generic EAV structure.

The database no longer sees projects.

It sees rows.

The database no longer sees budgets.

It sees attributes.

The database no longer sees regions.

It sees values.

The business meaning has been abstracted away.

The optimizer must reconstruct reality before it can answer the question.

That reconstruction becomes increasingly expensive as complexity grows.

The Optimizer's Blindfold

Modern relational databases are astonishingly sophisticated.

Query planners estimate cardinality.

Indexes accelerate lookups.

Statistics guide execution paths.

Storage engines optimize physical access patterns.

But these systems work best when the structure of the data is visible.

Generic relationship models obscure that structure.

The optimizer loses context.

Indexes become less effective.

Execution plans become harder to predict.

Queries become increasingly dependent on joins, pivots, and transformations.

Performance begins degrading in ways that are difficult to diagnose.

The flexibility remains.

The efficiency disappears.

When Graph Thinking Meets Relational Storage

The situation becomes even more interesting when teams attempt to implement graph-like thinking inside relational databases.

Everything becomes a node.

Everything becomes a relationship.

Everything becomes connected.

Conceptually, this feels elegant.

Architecturally, it often creates friction.

Relational databases are optimized around structured entities.

Graph databases are optimized around traversals.

Trying to force one paradigm into another usually means inheriting the weaknesses of both.

The schema becomes harder to understand.

The queries become harder to optimize.

The operational complexity increases.

The flexibility feels liberating.

The execution engine disagrees.

The Cost Appears Gradually

This is what makes generic models dangerous.

They rarely fail immediately.

Early development accelerates.

Requirements are accommodated quickly.

Stakeholders are impressed.

Then the platform matures.

Data volume grows.

Queries become analytical.

Historical records accumulate.

Reporting requirements expand.

The same flexibility that accelerated development begins slowing everything else down.

The architecture reaches a familiar point.

The component originally introduced to reduce complexity has become a source of complexity.

We have seen this pattern before.

Entity-Centric Modeling

Mature systems often move in the opposite direction.

Not toward greater abstraction.

Toward greater specificity.

Instead of storing:

Entity
Attribute
Value

they define:

Project
Schedule
Issue
Contract
Asset

The schema becomes more opinionated.

Less generic.

More explicit.

This feels restrictive.

In reality, it allows the database to do what databases do best.

Understand structure.

Optimize access.

Execute efficiently.

The model stops describing everything.

It starts describing the business.

A More Important Lesson

This article is not really about EAV.

Nor is it about graph models.

It is about a recurring architectural misconception:

Flexibility is free.

It isn't.

Flexibility is one of the most expensive features a system can possess.

Sometimes that cost is justified.

Sometimes it is not.

The mistake is assuming flexibility arrives without trade-offs.

Every layer of abstraction conceals information.

Every concealed detail reduces the system's ability to optimize itself.

Eventually, the architecture must decide:

Do we want infinite flexibility?

Or

Do we want predictable performance?

Most mature systems discover they cannot maximize both simultaneously.

Looking Ahead

So far, this series has explored how complexity spreads through systems.

Operational databases became analytical bottlenecks.

Visualization tools became business-model bottlenecks.

Dependencies became reliability bottlenecks.

Generic schemas became performance bottlenecks.

Next, we move from data structures to runtime behavior.

Because even perfectly designed schemas can bring down a system when memory management goes wrong.

Modern failures rarely look like traditional crashes.

More often, they look like healthy systems slowly suffocating under unresolved promises, blocked event loops, and unbounded memory growth.

And that is where we go next.

Part 5 of the Architecture of Information Systems series.