Affinity built its name on relationship depth. For wealth advisors, consultants, and relationship-driven sales teams, the ability to map not just direct contacts but the full web of introductions, warm paths, and decision influence is genuinely useful. But we started hearing the same complaint from larger teams: the graph gets sluggish. At 150 contacts it's snappy. At 250 it noticeably slows. At 500, you're waiting. We decided to measure it properly. We ran load tests on Affinity, HubSpot, and Orin's CRM using a realistic wealth advisor dataset—500 contacts, 1,200 relationships (introductions, deal history, shared experience), 80 active deals tracked across the network. We measured three things: graph-render time on the contact card, search latency when filtering by relationship type, and sync lag when a single contact record updated. The results expose a real architectural choice—and why it matters for your workflow. Affinity's graph: Fast at 100, slow at 300 Affinity's relationship graph is genuinely beautiful. Visualizing a contact and their warm paths to decision-makers is the reason advisors pay for the platform. The graph renders the contact, their direct connections, secondary connections, and shared attributes (alma mater, industry, fund manager cohort). For 100 contacts with loose networks, this is instant. But the graph is a real-time calculation, not a cache. When we loaded 500 contacts with densely connected relationships—which is exactly what a wealth advisor accumulates—the render time climbed: 100 contacts, 200 relationships: 240ms graph render. Imperceptible. 250 contacts, 600 relationships: 1.2 seconds. Noticeable pause when opening a contact detail. 500 contacts, 1,200 relationships: 3.8 seconds to render the full graph. The UI briefly shows a spinner. Worse, searching for contacts by relationship type ("Show me all intros from the Northwestern network") hit latency walls around 250 contacts. Affinity's search works by walking the relationship tree in real time. Narrow enough filters still worked fine, but broad searches started timing out or degrading to simple text match. This isn't a bug. It's a design constraint. Affinity chose deep, real-time graph calculation over denormalization. That gives you absolute accuracy—if a relationship changes, the graph updates immediately. But it trades performance for that guarantee. HubSpot's activities table: Faster, shallower HubSpot doesn't build a relationship graph. Instead, it stores relationships as contacts with a "Related Contacts" field and tracks touchpoints in the Activities timeline. This is a simpler model. It's also faster. Contact load time in HubSpot stayed under 600ms even at 500 contacts because HubSpot loads the contact card and its related-contacts list in parallel, without calculating paths or secondhand connections. But the trade-off is visibility. In Affinity, you immediately see why a contact matters to your network—warm introductions, shared fund managers, deal history. In HubSpot, you see a list of related contacts and activity dates. You don't see the depth of the relationship or the strength of the path. If you want to map a warm intro chain, you have to click through related contacts one by one. For a sales team working broad leads, that's fine. For wealth advisors or deal origination teams where the entire business model is built on relationship depth, HubSpot's model leaves money on the table. We also tested HubSpot's search across relationship fields. It was consistently faster than Affinity—under 800ms even with complex filters—but search only ran against contact properties and activity notes, not the implied relationship graph. You can't ask "Which contacts introduced me to people who manage ₹50M+?" You have to search by explicit tags you manually apply. Why Affinity's graph breaks: The math Affinity's performance wall isn't mysterious. A contact's relationship graph is computed as the transitive closure of three edges: direct intros, shared experiences, and deal history. With N contacts and roughly 2.4 relationships per contact (our test dataset), the number of potential paths grows as O(N²). At 500 contacts, that's 250,000 possible connections. Even checking which ones exist, filtering by recency and type, and rendering the top 20 is expensive. Affinity optimizes this with smart caching and limiting the depth Affinity displays to two hops. But when you have enough densely connected advisors, you hit the law of physics. The graph calculation gets slower, and if the server is also handling other requests, the UI hangs. This is exactly the scenario large wealth management teams hit: 500+ advisors, each with hundreds of warm relationships, trying to collaborate on deal origination. Affinity remains the best tool for seeing relationship depth, but at that scale you need to accept latency or switch the model. Orin's unified inbox: Avoiding the graph problem We tested Orin with the same dataset. Orin doesn't solve the rel