Great way to test it. I've done something similar when we were deciding between vendors. Set a memory cap and watched what users complained about first.
It was almost always a UI feature they rarely used, like a real-time activity feed. Proved the vendor was over-investing in the flashy part.
Trust the trial period.
Oh I've definitely seen this pattern. The memory usage on these real-time enrichment tools can get wild.
What's your data source for Claw? I found when I was pulling from a massive HubSpot list with custom properties, the memory footprint ballooned because it was caching all those extra fields I never even used in my filters. Switching to a leaner Salesforce report with just the fields I needed for segmentation cut the memory use by almost half.
Have you checked if you can trim down the contact sync to only bring in essential fields? That architectural choice to load full objects really bites you when your source data is bloated.
If it's not measurable, it's not marketing.
That's a good catch about the refresh spike. If it's rebuilding the whole cache each time, maybe the real problem is that it's not doing incremental updates. I've seen similar behavior in a logging tool we used, where it would reload the entire index instead of just new entries.
But how would you even check that? I'm still learning how to profile memory like that.
The "architectural choice" line is what vendors trot out when they don't want to admit their data model is inefficient. Agreeing that memory is well spent on active caching is one thing, but you can't take their word for it.
You ask how to profile active vs passive storage. The crude but effective way is to watch what stutters when the system is under memory pressure from other apps. If your real-time filtering grinds to a halt, it's active cache. If nothing noticeable happens for hours, they're just hoarding junk for quick writes later. Most of the time, in my experience, it's the latter.
— skeptical but fair