A proposal moves a CPU-heavy pricing calculation from the application tier into database procedures so it runs next to the data. How would you evaluate that proposal from a capacity and scaling perspective?

## Reframe the proposal 'Run it next to the data' is a real principle, but it is about data movement, not about the database being a better computer. The right question is what the move removes. Two very different cases hide behind the same sentence: - **Data-reduction work.** The computation reads a large volume and emits a small result - aggregation, matching, filtering, joining. Running it in the database removes rows crossing the network, the serialization and deserialization on both ends, and often the memory pressure of holding them client-side. This can be a large net win even though database CPU rises. - **Pure computation.** The computation reads roughly as much as it writes and spends its time in arithmetic or rules evaluation. Moving it relocates CPU without removing any transfer. That is the case in the proposal as stated, and it needs a much stronger justification. ## Asymmetry of the tiers The reason this matters is that the two tiers do not scale alike. **Application tier.** Stateless instances behind a load balancer. Capacity is a number in a config; failure of one instance is absorbed; a runaway workload on one instance is naturally bulkheaded from others. Adding capacity takes minutes and costs commodity money. **Primary database.** Usually exactly one node accepts writes. Its CPU is shared by every session, so a heavy procedure competes with the transactional queries that pay the bills - and unlike an application instance, there is no isolation boundary between them. Connection counts are bounded (each backend costs memory and scheduler attention), so saturation shows up as queueing and latency spikes across the board. Scaling options are, in order: vertical (bounded, needs a failover to apply), read replicas (cannot take write-path or read-your-write logic), and sharding or read-model offload (a major project, months not minutes). Failover itself is an event you would rather not trigger. **Cost.** Where licensing is per core, a core in the database can cost several times a core in the application tier, before considering that databases are typically provisioned for peak with generous headroom. ## How I would evaluate it concretely 1. **Quantify current cost.** CPU-milliseconds per pricing operation in the application, operations per second at peak, and bytes currently transferred to perform it. 2. **Prototype the procedural version** and measure the same: database CPU per operation, and bytes no longer transferred. Procedural languages in the database are usually slower per unit of computation than a compiled or JIT-ed application runtime, so expect the CPU number to rise, sometimes substantially. 3. **Convert to headroom.** Express the added load as a percentage of the primary's peak CPU, and check what that does to the latency of unrelated queries under peak concurrency - not average, peak with contention. 4. **Check the tail.** Does the procedure hold locks or a transaction while computing? Long-running procedural work inside a transaction adds lock hold time and blocks cleanup of old row versions, which damages the whole instance far beyond its CPU share. 5. **Ask what else changes.** Testability, deployment, lock-in, ORM friction - the non-capacity costs still apply and should be priced. 6. **Define the exit.** If it does saturate the primary, what do we do? If the honest answer is 'buy a bigger instance and hope', the proposal is under-baked. ## Alternatives that usually dominate - **Push down the reduction, keep the rules up.** Let SQL do the filtering, joining, and aggregation, and return the compact set the calculation needs. This captures most of the data-locality benefit with none of the procedural cost. - **Cache or precompute.** If pricing inputs change slowly, precompute and store results, or maintain them asynchronously. - **Move the work off the write path entirely.** Read replicas, a separate analytics store, or an asynchronous worker can absorb heavy computation without touching the primary. - **Batch smarter.** Often the perceived need to move logic down is really a chatty access pattern, fixable with set-based queries. ## The judgement to express Say yes when the calculation is a data-reduction step over volumes that are expensive to ship, when the database has demonstrated headroom, and when the team accepts the testing and deployment discipline. Say no when it is pure computation relocated onto a shared, hard-to-scale, expensively licensed tier, especially when the application side has elastic capacity sitting idle. And in both cases, insist the decision rests on measured numbers with a defined rollback, because this is a decision that is much easier to make than to reverse.