You usually feel a brittle data model before you can precisely explain it. Seemingly small schema changes ripple across services. Migrations feel risky even when the change is trivial. Engineers avoid touching core tables because every attempt triggers regressions in places nobody expected. This brittleness rarely comes from a single bad decision. It emerges from a series of reasonable choices made under delivery pressure, incomplete domain understanding, or premature optimization. Over time, those choices harden into structural constraints that slow teams down and increase operational risk. The good news is that brittleness follows recognizable patterns. Once you can name the mistakes that created it, you can design your way out with far more confidence.
1. Modeling implementation details instead of domain concepts
One of the fastest ways to create brittleness is letting storage or ORM constraints drive the model. Tables end up mirroring service internals rather than real business concepts. This works initially because it accelerates delivery. Over time, as workflows evolve, the model resists change because it lacks semantic meaning. Eric Evans’ Domain-Driven Design work shows that models anchored in domain language adapt better because changes map to real concepts, not technical artifacts.
2. Overloading single tables with multiple responsibilities
Brittle schemas often hide behind a few overloaded tables that try to do too much. Status flags, nullable columns, and conditional logic pile up to support divergent use cases. Each new feature increases coupling. This is common in legacy monoliths where a single “orders” or “users” table becomes a dumping ground. The failure mode shows up during migrations, where no change feels safe because too many code paths depend on subtle invariants.
3. Treating schema changes as rare, high-risk events
When schema evolution is painful, teams naturally avoid it. That avoidance creates a feedback loop where models fossilize. In contrast, teams running expand and contract migrations with strong backward compatibility treat schema change as routine. Brittleness often signals that migrations lack tooling, rehearsal environments, or rollback paths, not that the model itself is inherently complex.
4. Encoding business rules directly into relational structure
Foreign keys, constraints, and triggers are powerful, but brittleness appears when they encode volatile business rules. When policies change, the schema becomes the bottleneck. Many high-scale systems move complex rules into application or domain layers while keeping the data model focused on invariants. This tradeoff increases application complexity, but it restores adaptability where the business changes frequently.
5. Ignoring data ownership boundaries
Shared databases across teams create invisible coupling. When multiple services write to the same tables, every schema change becomes a coordination problem. Amazon’s service ownership model, where teams own their data and expose it through APIs, emerged from repeated scaling failures. Brittleness here is not technical, it is organizational, and the schema reflects that reality.
6. Optimizing for today’s queries instead of tomorrow’s questions
Query-driven modeling leads to schemas that perform well for known access patterns but collapse under new ones. Indexes, denormalization, and precomputed aggregates accumulate quickly. Over time, performance optimizations harden into structural constraints. Teams that survive this phase tend to separate write models from read models, even if they never fully adopt CQRS.
7. Lacking a clear strategy for historical data
Brittle models often treat history as an afterthought. Columns get overwritten, audit tables appear late, and temporal queries become expensive or inaccurate. Systems that plan for history early, whether through event logs or explicit versioning, tolerate change far better. Event-sourced systems, despite their complexity, demonstrate how explicit history reduces fear when evolving models.
Closing
A brittle data model is rarely the result of incompetence. It is the product of rational decisions made without long-term feedback. The key is recognizing which constraints still serve you and which ones are artifacts of past tradeoffs. By shifting focus toward domain clarity, ownership boundaries, and safe evolution, you can turn a fragile schema into a foundation that supports change instead of resisting it.
