In nearly every practical scenario, the scaling bottleneck lies in network throughput. Trying to scale by putting network I/O between computation and storage is a bit like trying to separate a rocket engine from its fuel tank with a garden hose.
> De linking them means you can scale the two appropriately independently.
It's definitely situational, and this can be true! But, generally its this kind of scaling optimization on everything that has us drowning in microservices today. If we can afford to "steal" some compute from the DB server, and minimize the amount of infra spun up for things that are basically scripts, I consider that a win.
We de-linked the two because there was no practical way to autoscale the database, but autoscaling microservices is easy. Obviously you want to be very cautious about how you treat inelastic compute.
Today there are lots of practical ways to autoscale databases and colocating data and compute is generally good for performance and simplicity (your mileage may vary for simplicity).
It depends on the workload and being able to go both ways is powerful. If compute dominates every other dimension, then decoupling compute from data makes sense and you see a substantial performance improvement decoupling those workloads.
If Network I/O between your compute and data dominates every other dimension, you might want to to collocate compute and data.
Being able to fit the architecture to the performance of the workload is a good thing.
It depends - usually moving computation closer together is much more performant. You may be underutilizing your DB or spending a lot of roundtrips on networking and this is a good way to reclaim that. It does not prevent you from having services - it just reduces the #.
It could be for some use cases, but there are significant efficiency advantages to processing the data where it lies instead of shipping a copy to separate compute services.
Decoupled scales, but you end up replicating the dataset in compute node caches, which is expensive.
Ideally you want scalable storage with compute (assuming really large datasets), so you can move the computation, which usually is small, close to the data.
In any case, it's not one size fits all, and each problem space matters.
Isn’t that a step backwards? De linking them means you can scale the two appropriately independently.
I guess if you’re using could and can “steal” a bit of compute that way it makes sense.