But it's not. Period. As an application dataset grows and presumptions of yesterday blow through sane limits, you will re-visit this topic. It happens again and

But it's not. Period. As an application dataset grows and presumptions of yesterday blow through sane limits, you will re-visit this topic. It happens again and again. Hypothetical example: Boss asks if you can fit several millions of products into the database. Keep them up-to date by setting related prices on them. Each synchronization task needs to be aware of product deltas: is it available, sold out, on sale and so on. Oh and there are many suppliers, catalogs. All the while you're running set intersect, difference and so on on multi-million count objects, you still need to be aware that access to this data needs to be consistent and sane. Access times of several hundreds of milliseconds are not acceptable. Obvious solutions is to distribute the load, counting and updating amongst machines. Load publicly available data from high performance memory tables. At some point, it all comes unravelled when you get a request for custom sub-sets where each one can live queries by price, text, brand ... Memory bound problems are just that. At some point you hit the wall. I think planning for that impact is the best insurance a shop can make.