The answer, briefly: Salesforce is a poor fit when the work is high-volume machine-to-machine processing, when the data has no relationship to a customer or a sales process, when you need sub-second guaranteed latency, or when the per-user licence model prices out the people who would need access. Building those things on the platform is possible and usually a mistake you pay for monthly.
The four genuine mismatches
High-volume transaction processing. Governor limits exist because the platform is multi-tenant, and they are not negotiable. A system processing millions of small events per hour is fighting the architecture on every one. Salesforce is very good at a hundred thousand records a day and poor at a hundred thousand records an hour.
Data with no business-object shape. Time series, sensor readings, application logs, clickstream. These have no owner, no sharing requirement, no lifecycle, and enormous volume. Storing them in Salesforce costs storage you could buy a hundred times more cheaply elsewhere, and you gain nothing from the platform’s strengths.
Guaranteed latency. Nothing on the platform offers a latency guarantee. Most operations are fast. A small proportion are not, and you cannot tell which in advance. Anything with a hard real-time requirement belongs somewhere you control the resources.
Everyone needs access. The licence model prices per user. A system every employee touches twice a year, or one customers use directly at scale, becomes expensive in a way that has nothing to do with how well it works. Experience Cloud changes this calculation and does not remove it.
The arguments that are not reasons
Several common objections do not hold up:
- “It is too slow.” Usually a selectivity or a data volume problem with a fix, covered in why your query got slow. Rebuilding elsewhere often reproduces the same problem.
- “We cannot do X declaratively.” Apex exists. This is a staffing argument, not a platform one.
- “The limits will stop us.” Sometimes true, and worth testing at volume before deciding. Most limit failures are design problems, not ceilings.
- “It is expensive.” Compared to what, including the cost of building and operating the alternative for five years. Frequently the answer still favours building elsewhere, and the comparison should be honest.
The hybrid that usually wins
The best answer is often not either. Keep the customer, the relationship and the process in Salesforce, where the sharing model and the reporting genuinely help, and put the volume elsewhere.
A concrete shape: millions of usage events land in a data warehouse. A nightly job aggregates them per account. Salesforce holds the aggregate, and users see a usage summary on the account with a link out to the detail. Salesforce stores thousands of records rather than millions, and everything it is good at still applies.
External objects through Salesforce Connect are the other version of this: the data stays outside and appears in the UI, at the cost of no triggers, no roll-ups and limited querying.
Sunk cost, honestly
The question is rarely asked before a build. It is asked two years in, when something is struggling, and the real question is whether to move it now or keep paying.
The honest framing is forward-looking cost only. What does the next two years cost if it stays, including the workarounds, against the migration plus the next two years elsewhere. What has already been spent is not an input, and it is the thing everyone in the room is actually weighing.
When it is clearly the right choice
For balance, the platform is hard to beat when the work has a customer at the centre, needs a sharing model more complex than “team can see team”, requires audit and compliance evidence, must be changed by non-developers, and needs to be running next quarter rather than next year. That combination is common and it is what the platform is genuinely for.
Frequently asked
Can Heroku or an external service fill the gap? Often, and it keeps the relationship in one vendor. Evaluate it as you would any other platform rather than because it is adjacent.
What about Data Cloud for the volume case? It is designed for exactly that, and it is a separate product with a separate cost. Worth evaluating on its own terms, not assumed because it is Salesforce.
How do I make the case internally? With a number. Cost per transaction, or projected storage at current growth, or the licence count needed. Architectural arguments lose to commercial ones. Commercial arguments win both.
