Teams buy Clay for the personalization demos and quit three months later because of table sprawl. Forty tables, no naming convention, every campaign a fresh copy of the last one with two columns changed. That's not a Clay problem. That's what happens when you use a database like a doc.
Treat tables like schemas
The pattern that survived three client deployments:
- One source-of-truth table per entity. Companies, people, signals. Everything else references these.
- Campaign tables are views, not copies. They pull from the entity tables with lookups; they never own data.
- Enrichment columns are named by provider and date.
linkedin_headcount_2026_05beatsheadcount_final_v2_REAL.
Joins are the whole game
Clay's lookup column is a foreign key. Once you treat it that way, the questions get easy. Which people belong to accounts with a fresh funding signal? That's a join. Which accounts have three or more signals this month? That's a group-by.
Copywriting is the last five percent. If the data layer under it is clean, a mediocre first line with a true, specific reason to reach out beats a brilliant one built on a stale list.
Draft post. Schema diagrams and a template table set to follow.