> There cannot be strong evidence both for and against something,

Of course there can be. Multiple cases exist. Light as a particle and light as a wave.

That's a great example of misinterpreting evidence—to see the evidence that light is a particle as strong evidence that it's not a wave, or vice versa, would be a misinterpretation of the evidence based on the incorrect assumption that it can't be both.

There is a single, coherent thing that light is, which produces the evidence we see. Some of that evidence is consistent with being just a wave, some is consistent with being just a particle, and yes, it's also strong evidence that it's not just a particle and not just a wave. We don't know all the details yet; "both a wave and a particle" is a pretty good approximation given our current level of knowledge, as is "sometimes a wave and sometimes a particle."

But picking the description "It's either just a wave or just a particle depending on how you feel about it, and there's no evidence that will help us because the evidence is contradictory" is wildly wrong and unscientific.

Ad Tech has no need for realtime data viewing or aggregation (in this manner), even for platform log data. Offline parallel processing is the standard. Redshift is particularly efficient, while others use Spark or other ad-hoc solutions.

For users, you always want mediation/adjustment steps that (can) modify realtime data to provide timesliced totals. For developers/administrators, you want to be able to persist data. Running totals in memory are too fragile to be reliable. There is an assumption of errors, misconfigurations, and bad actors at all times in AdTech.

Has no need? Did you just make this up?

We used MemSQL for real-time data for 2 years. All data is fully persistent, but the rowstore tables are also fully held in memory compared to columnstores which are mainly on disk. There's nothing fragile about it. SQL Server's Hekaton, SAP's HANA, Oracle's Times Ten, and several other databases do the same.

Timesliced totals is just a SQL query, and mediation or some other buffer from live numbers for customers is up to every business to decide, not some default proclamation for an entire industry.

Actually RTB's do need to do processing quickly - RTB stands for Real-Time Bidding, and bids are rejected after 250 ms.