Notion contact databases feel snappy at 50 rows. At 200 rows, you notice the first stutter when you filter by company or open a relation. At 500 rows, the database is technically functional, but something has shifted: queries take 3–5 seconds instead of 300 milliseconds, relation dropdowns lag, and bulk updates freeze the interface for 10–15 seconds. By 1,000 rows, you're not imagining it—Notion's design assumes your database is a reference tool, not a transactional system. This post documents the exact performance cliff, shows you where it happens, and walks through a migration checklist so you know what data leaves cleanly and what needs cleanup before you switch. The Performance Cliff: What Breaks and When Notion's database engine works by loading your entire table into the browser and filtering in JavaScript. This works beautifully at 100–200 rows. At 500 rows, you're asking JavaScript to filter, sort, and render 500+ objects with their relations intact. The degradation is not linear. Query Lag (300ms → 3–5 seconds) A simple filter—"Company = Acme"—completes in under 300ms at 100 rows. At 500 rows, the same filter takes 2–3 seconds as Notion's client-side engine scans and matches. At 1,000 rows, expect 5–8 seconds. This matters because sales teams checking a pipeline live during a call now have to wait while the screen refreshes. Relation Bloat If you have a "Contacts" table linked to a "Companies" table, opening a Contact record with a Companies relation dropdown at 100 companies takes 500ms. At 500 companies, it takes 3–4 seconds and often times out, leaving you staring at a spinner. A sales rep trying to assign a contact to a company in a live meeting now has a broken workflow. Bulk Update Freeze Updating 50 contacts via Notion's bulk-edit interface is instant. Updating 200 contacts in one pass can lock the interface for 10–15 seconds. Some users report page crashes when bulk-editing datasets over 300 rows. If you run a marketing campaign and need to tag 400 contacts at once, Notion becomes unreliable. Filter + Sort Compounding A single filter runs at the cliff described above. A filter plus a sort—"Company = Acme, sorted by Last Contact date"—compounds the lag. Two filters plus a sort can take 8–12 seconds. Multi-field sorting on large tables essentially breaks. The real threshold is not 500 rows; it's 500 rows with relations, filters, and active team use. A contact database sitting read-only at 2,000 rows may feel fine. A 600-row contact database with four team members filtering and updating simultaneously will feel broken by month 3. Why Notion Hits This Wall Notion is designed as a note-taking and reference tool with database features bolted on. The architecture does not assume you are running transactional queries against a contact table 50 times per day. The Notion API is rate-limited and slow by design; the web client loads and processes everything in the browser; and there is no query optimization layer. A real CRM platform (Salesforce, HubSpot, Pipedrive, or Orin's CRM ) has a backend that indexes contacts by company, date, and status, and returns results in milliseconds because it queries an optimized database, not JavaScript in your browser. Notion's performance cliff is not a bug—it's the ceiling of the architecture. You cannot make it faster by renaming fields or compressing data. You have to switch platforms. Migration Checklist: What Moves, What Stays, What Rebuilds Data That Exports Cleanly (No Cleanup Needed) Contact names, emails, phone numbers: These export as plain text and import directly into any CRM. Expect zero friction here. Company names, if standardized: If your Notion relation links each contact to a single company record with a consistent naming scheme, this exports cleanly. If you have "Acme Inc.", "ACME", and "Acme" in the same field, stop and deduplicate first. Custom fields with static values: A "Region" field with values like "EMEA", "APAC", "Americas" exports and maps cleanly. A "Notes" field exports as text. Dates: Created dates, last contact dates, and deal close dates export as ISO-formatted dates that any platform imports correctly. Data That Requires Cleanup Before Migration Linked relations with duplicates: If you have 50 Notion records all linking to "Acme" but spelled three different ways ("Acme", "ACME Inc.", "Acme Corp"), your new CRM will treat them as three separate companies. Deduplicate and standardize in Notion first. Use Notion's rollup feature or a manual audit to surface duplicates; fix them before export. Multi-select or checkbox fields with inconsistent values: If a "Deal Stage" field has "Qualified", "Qualified Lead", and "QL" meaning the same thing, standardize these to one value before export. A 30-minute find-and-replace in Notion saves hours of data cleanup after import. Phone numbers without country codes: If your Notion database has mixed formats ("555-1234", "(555) 123-4567", "+1 555 123 4567"), your new CRM may not recognize them as vali