The Architect’s Manifesto

1. What is EDD?

EDD is a non-destructive schema philosophy. It treats the database as an append-only ledger. Schemas evolve by adding, never by subtracting.

2. Significance

EDD decouples Persistence from Application Logic. It eliminates the “Migration Trap.” It ensures the DB is a Universal Recipient for all versions.

3. Advantages vs. Disadvantages

Advantages:

• Perfect Rollbacks: Old binaries always work.
• Zero Downtime: No table locks for drops/renames.
• Solo-Friendly: Reduces cognitive load and risk.

Disadvantages:

• Schema Bloat: Unused columns persist.
• Data Integrity: Must be managed in Go, not SQL.
• Messy Tables: Requires documentation/views to clean.

4. Relations in EDD

Relations are associations, not enforcements. Banish FOREIGN KEY constraints at the SQL level. Use the Go binary to validate link integrity.

5. Value of Enforcing It

Enforcement creates a Hard Safety Rail. It prevents “accidental” destructive changes by AI agents. It turns your DB into a permanent audit log of your logic.

6. How to Enforce It

• Nullable Only: Every new field must be optional.
• No Drops: Disable DROP and RENAME permissions.
• Soft Relations: Use IDs without hard SQL constraints.
• Version Mapping: Map structs to active columns only.

7. Core Philosophy Advice

• DB is a Bucket: It holds data; it doesn’t judge it.
• Logic is the Brain: Go knows what’s valid; SQL doesn’t.
• Storage is Cheap: Uptime and sanity are expensive.
• Accept the Mess: A messy working DB beats a clean dead one.