near-data computing
Suppose you run a delivery company, and a customer asks 'how many of my thousand packages weigh over five kilos?' You could ship all thousand packages to head office, weigh them there, and ship back the answer 'forty-two' — a colossal waste of trucks. Or you could send a clerk out to the warehouse, weigh them where they sit, and send back just the number. Near-data computing is that second idea applied to computers: rather than hauling vast amounts of data to a central processor, you move a little bit of computation out to where the data already lives, and ship back only the small answer.
Near-data computing is a broad family, and it is useful to see it as a spectrum. At one extreme is processing-in-memory, putting compute inside the memory chips themselves. A gentler version puts a modest processor right next to a memory stack or on the same package — 'near-memory' rather than strictly 'in-memory'. Further out, 'computational storage' puts a small processor inside an SSD, so a query like 'count the rows matching this filter' runs on the drive and returns only the count, not the whole dataset. In every case the principle is identical: computation is cheap and plentiful, but moving data is slow and burns energy, so push the work toward the data instead of pulling the data toward the work.
This matters because the dominant bottleneck and energy cost in modern systems is data movement, not arithmetic — a theme that runs through the whole post-Moore landscape. Near-data computing is often easier to adopt than full processing-in-memory, because you can use a more capable ordinary processor placed close to the data rather than squeezing logic into memory cells. The honest caveat is that it pays off only when the computation reduces the data a lot — like a filter or an aggregate that turns gigabytes into a few numbers. If the operation must send most of the data back anyway, moving the compute out there buys you little, and the added complexity of programming and managing these distributed little engines is not worth it.
A computational-storage SSD holds a 100 GB log file. The database asks the drive 'return only the lines containing ERROR'. A small processor inside the SSD scans the file locally and sends back the matching 50 MB instead of streaming all 100 GB to the CPU — a 2000-fold reduction in data crossing the bus, with the same final answer.
When the work shrinks the data, doing it near the data and returning only the answer beats hauling everything home.
Near-data computing only wins when the computation greatly reduces the data — a filter or aggregate. If most of the data must travel back anyway, pushing compute outward adds complexity for little benefit.