Flexible Schema, Solid Guarantees
There's a classic tradeoff in data systems: flexibility vs. guarantees. Rigid schemas guarantee data integrity but require expensive migrations for every change. Flexible schemas adapt easily but offer weak guarantees — anything can be stored, and the data quality degrades over time.
Business applications sit in the middle of this tradeoff and have to manage it carefully.
The Problem with Fully Rigid Schemas
Traditional business databases define every field upfront, enforce types strictly, and require schema migrations to change anything. This works well when requirements are stable and fully understood at design time.
Business requirements are never fully understood at design time. New fields are needed. Existing fields need to change type. Processes evolve. A system that requires database migrations for every adaptation creates a feedback loop where the schema drifts from the business's actual needs because adapting it is too costly.
The Problem with Fully Flexible Schemas
At the other extreme, document databases with entirely flexible schemas adapt to anything — and guarantee nothing. Fields drift in type across records. Required fields get missed. Relations become inconsistent. The data becomes hard to query reliably because you can't assume anything about its structure.
For operational business data, this is genuinely dangerous. Billing records with inconsistent field presence. Contracts missing required approver fields. Status values that don't match the defined workflow. The platform can store the data, but can't guarantee it means what you think it means.
Our Approach
Swifty uses a definition-driven flexible schema. Object types are defined with fields, types, and constraints. Those definitions are enforced at write time — required fields must be present, field types are validated, relation fields must point to valid records.
But the definitions themselves are flexible and can change without migration. Adding a new field to an object type takes effect immediately. Existing records that predate the field simply lack a value for it, which is handled consistently.
The result: you get the adaptability of a flexible schema — adding fields when you need them, changing definitions as your process evolves — while maintaining integrity guarantees on every write.
Where the Guarantees Live
The key is that validation happens at the definition level, applied at write time. The underlying storage is flexible enough to evolve, but the application layer enforces what the definition says the data must look like.
This is the right layer for guarantees in a multi-tenant platform. Tenant-specific definitions can be different; the enforcement mechanism is shared and reliable.
Flexibility and integrity aren't mutually exclusive. They're a design problem with a workable solution.