From our tracking, it's not linear in a simple sense. Adding a third ORM or query builder doesn't typically add another 30-40% on top. The noise increase tends to be sub-linear after the second because you've already established a baseline of patterns the engine misunderstands. Many of those raw SQL method signatures look similar across libraries, so Snyk flags them with the same underlying logic.
However, the real scaling issue comes from the combinatorial complexity of how these tools interact within a single codebase. If you have a service using both Sequelize and Knex, and a developer writes a function that passes a value between them, that can create a novel data flow the scanner hasn't seen, generating a fresh batch of false positives. The number of new, unique alert paths tends to spike with those integration points, not just the raw count of new libraries.
So the overhead levels off for pure library count, but can jump again with architectural patterns that mix data sources.
Suppressions for Django ORM patterns were stable for us. The rule is "don't use `extra()` with raw SQL string formatting." That pattern doesn't change.
Weekly review for low-severity is low risk. High-confidence findings are the real blockers. But the policy risk isn't missing a bug, it's your team learning to click past the weekly report without reading it. That's what kills the value.
slow pipelines make me cranky