Notion sells itself on the promise of connected databases—one source of truth, relational properties, rollups that calculate automatically. It’s a compelling pitch, especially if you’re managing clients, projects, content calendars, and invoices in the same workspace.
But relational databases in Notion come with friction most solo operators don’t anticipate until they’re neck-deep in broken views and slow-loading pages. Sometimes the smarter move is to duplicate your data instead of relating it.
When relations make sense
Relational properties work well when you need live, two-way sync between databases. A classic example: a Projects database linked to a Clients database. You relate each project to a client, and Notion automatically shows all projects under that client’s page. Add a rollup, and you can calculate total hours billed or outstanding invoices without touching a spreadsheet.
This setup shines when:
- You frequently filter or group by the related property (e.g., “show me all active projects for Client X”).
- The related database is relatively small—under 500 rows.
- You need rollups or formulas that pull data from the related table.
But the moment your related database grows past a few hundred entries, or you start chaining relations (Projects → Clients → Invoices → Line Items), Notion’s performance starts to sag. Pages take three to five seconds to load. Inline databases stutter when you apply filters. Mobile becomes nearly unusable.
When duplication beats relation
Duplication means copying static data—like a client name or project status—directly into the database where you need it, rather than linking to another table. You lose the automatic sync, but you gain speed and simplicity.
Here’s when to duplicate:
- High-volume databases. If your content calendar has 1,000+ rows and you’re relating each post to an author database, every view recalculates those links. Duplicating the author name as plain text makes filters instant.
- Archival data. If you’re logging completed projects or past invoices, the data rarely changes. A relation adds complexity with no upside—just copy the client name and close the loop.
- Cross-workspace collaboration. Notion’s database relations don’t work across workspaces. If you’re sharing a content calendar with a client but keeping your internal project tracker private, duplication is your only option.
Yes, you lose the ability to update a client’s name in one place and see it cascade everywhere. But for most solo operators, that’s a theoretical problem. You’re not renaming clients every week. The performance gain is real; the sync risk is hypothetical.
The hybrid approach
You don’t have to choose one strategy for your entire workspace. I run a Content database with 800+ posts. Each post has a Topic property—but instead of relating to a separate Topics database, I use a multi-select dropdown. It’s technically duplication (the topic name lives in the Content database), but I can still filter, group, and count posts by topic without the relational overhead.
For high-touch workflows—like tracking sponsorship deals where I need live rollups of total contract value—I keep the relation. For everything else, I flatten the data.
Notion’s automation and API integrations (via Zapier or Make) can help maintain duplicated data if you do need occasional syncing. A zap can copy a client’s updated name into your archive database once a month, for example, without forcing every page load to recalculate a relation on the fly.
What this means for your workspace
If your Notion workspace feels sluggish, audit your relational properties first. Open your largest database, check the relations panel, and ask: Do I actually use this link, or am I just maintaining it because it feels like best practice?
Relations are a feature, not a requirement. Treat them like indexes in a SQL database—powerful when you need them, expensive when you don’t.
Using Notion to run your business? Reply with your biggest database headache—I’ll feature reader solutions in a future issue.