SA on Data Architecture: How to Design a Database That Scales
The database is the most important component of any software system. Five principles of good database design, four denormalisation patterns used in every SaaS, and the six-section data model design document delivered on every SA engagement.
Why the Database Design Determines Everything
The database is the most consequential component of any software system. Every other component is built on top of the data model. A correct data model enables all future features. An incorrect one makes every future feature more expensive. SA spends more time on database design than any other architectural component — and we teach every client why this investment pays back many times over.
What SA Applies to Every Data Model
Model the problem domain, not the UI
Database design should reflect the real-world entities and relationships in the problem being solved, not the current screens. The UI can be redesigned in hours. The data model is redesigned in weeks. Design for the problem, not for the interface.
Normalise first, denormalise deliberately
Start with a normalised model: no redundant data, every fact stored once, relationships expressed as references. Then deliberately denormalise specific fields for performance. Every denormalisation is a conscious decision with documented rationale, not a shortcut.
Every relationship is an architectural decision
When entity A references entity B, that relationship has query, security, and maintenance implications. Every relationship in the data model must be explicitly designed and documented with its business meaning.
Design for the queries you will need
The most expensive data model mistake is discovering after launch that the queries needed by the UI require joining five tables across multiple database round trips. Design the data model with the queries in mind: what will the dashboard show, what will list pages filter on.
Privacy rules are part of the data model
In Bubble, privacy rules are configured per data type and enforced at the database layer. SA designs privacy rules alongside data types — not after the database is built. They are integral to the data model design, not a separate step.
Pre-Calculating for Performance
Workspace
: active_project_count, total_task_count, member_count
Project
: open_task_count, completed_task_count
// Update on child create/delete via workflow
// Pattern 2: Denormalised parent data on child (avoid N+1 queries)
Task
: workspace (direct reference), project_name (text, stored on Task)
// Pattern 3: Pre-calculated billing metrics
Workspace
: mrr, current_month_revenue
// Updated by Stripe webhooks; dashboard reads instantly
// Pattern 4: Status aggregation
Project
: health_status (option set: On Track / At Risk / Off Track)
// Calculated by nightly scheduled workflow; displayed instantly
What SA Delivers on Every Architecture Engagement
| Section | Content |
|---|---|
| Entity Catalogue | Every data type with its purpose, fields, types, and relationships |
| Relationship Diagram | Visual representation of how data types connect |
| Privacy Rule Decisions | Every privacy rule with its business rationale |
| Denormalisation Decisions | Every denormalised field with source, update trigger, and performance rationale |
| Query Patterns | The major queries and how the data model supports them |
| Scale Considerations | Which types will grow fastest; where denormalisation should be added at scale |
Work With SA — Simple Automation Solutions
Pakistan’s leading no-code systems architecture practice. We design tech systems before we build them.
