Notion CRM feels elegant at 50 contacts. You build a database, link a few views, wire up some rollups, and it just works. But around contact 400–500, something shifts. Query times stretch. Filters start to lag. Multi-relation views become unusable. And if you've stored actual relationship context—call notes, deal stage, contact history—exporting it whole becomes a puzzle with missing pieces. We ran Notion CRM through real-world scaling. This is not theory. At 500+ contacts with moderate relational complexity (contacts, companies, deals, interactions), the platform hits hard limits on performance, view stability, and data portability. Some views survive. Most don't. And the exit—getting your relationship data cleanly into a real CRM—takes 14 days if you know what you're doing, or 6 weeks if you don't. Here's what breaks, what survives, and how to plan your move. Where Notion CRM falters at 500+ contacts Database lag is the first wall. A simple database view of 500 contacts with three filters applied (e.g., company = 'X', stage = 'active', created within last 30 days) takes 8–12 seconds to render on a fresh page load. On subsequent refreshes, cached loads drop to 2–3 seconds, but any filter change resets the clock. With 10–15 team members hitting the same database, you get queue contention and timeouts. Multi-relation views flatten under load. This is the killer for real deal work. Once you've linked Contacts → Companies, and Companies → Deals, and Deals → Interactions, a single view that tries to show all three relationships (e.g., 'Show me all contacts at Company X, their deals, and last interaction date') starts to fail. Rollups compute slowly. Relation filters ("where related company = X") become 30–40 second waits. By contact 600, these views are often faster to rebuild manually than to load. Exports lose relationship context and custom fields. Notion's CSV export works, but it's crude. Custom fields with formulas don't export—they export as computed values at export time, frozen. Relations export as comma-separated lists (sometimes unreadable). Lookup fields export as concatenated text. Multi-select fields export with pipes or commas that need parsing. You'll lose formula logic, calculated fields, and the ability to rebuild the exact schema you had. No audit trail, no task automation, no conditional workflows. Notion has database templates and simple forms, but no audit log of who changed what when. No automation to trigger actions (e.g., "when deal stage = won, send notification to finance"). No conditional routing. This isn't critical at 50 contacts, but at 500, you're flying blind on data integrity and can't automate routine deal handoffs. Which Notion CRM views actually hold up Not everything breaks. A few patterns survive the 500-contact threshold. Simple rolling 30-day contact list works. A database view with one filter (created within last 30 days), sorted by name, renders in 1–2 seconds at 500 contacts. No rollups, no multi-level relations, just contacts and a few basic fields. This view is fast because it's filtering the base table, not computing relationships. Single-relation lookups are usable. A view that shows "Contact + Company Name" (one relation level) stays fast. The database computes the lookup once and caches it. Filtering on that related field ("show me all contacts at Company X") is also fine—it's a native filter on an indexed field. Count and checkbox rollups survive. A rollup like "count of deals linked to this contact" stays quick. Button properties that route to a pre-filtered view stay fast. These are lightweight and don't require iterating over large result sets. Timeline and calendar views hold up well. If you have a date field (deal close date, last contact date), a calendar or timeline view of 500 records filters and renders cleanly. This is because the view is powered by a single date column and doesn't need to compute relations. The pattern is clear: the fewer relations you cross in a single view, the faster it stays. One relation = fast. Two or three relations = slow. Four+ relations = unusable by contact 500. What you'll lose in an export Exporting 500 contacts from Notion to a proper CRM (like Orin ) requires mapping. Here's what vanishes or transforms badly: Formula fields: Exported as static values. You lose the logic. Example: a field that says "days since last contact" is exported as numbers, not a formula, so they go stale on day one. Rollup fields: Exported as text or numbers, not relationships. Example: "count of deals" exports as a number, but Orin needs actual deal links to rebuild that count. Relations in free text: If you've stored company names or deal IDs in a text field (because linking felt too rigid), they don't re-link on import. You'll need to de-dupe and re-link manually or via a data integration tool. Linked databases and inline relations: A contact record linked to five different tables won't export neatly. You'll get one CSV per table and lose the