Theme 1 – SQL/relational databases remain the preferred analytics abstraction
Many commentators argue that for most analytical workloads, SQL and traditional databases are simpler and sufficient, making explicit stream‑processing models unnecessary.
- scott_s: “just default to SQL for all analytics and the database lens is the best way to think about streaming for analytics.”
- scott_s: “People get by with the existing programming languages and models, that seems to be fine.”
Theme 2 – Operational complexity and limited demand hinder widespread streaming adoption
Stateful, low‑latency streaming systems are seen as harder to operate and only needed by a narrow set of use cases.
- necubi: “very few companies actually need low latency processing. And continuously running, stateful systems are inherently more complex to operate and evolve compared to batch systems.”
- BenoitP: “People get by with the existing programming languages and models, that seems to be fine.” (implying the extra effort isn’t justified for most tasks)
Theme 3 – Streaming concepts (dataflow, event time, completeness) are still valuable and are being absorbed into databases/batch systems
Even if users don’t program streams directly, the underlying ideas improve query engines, materialized views, and future distributed databases.
- scott_s: “Databases already have a dataflow style architecture: that’s how they implement queries. Because SQL is relational, SQL queries become dataflow execution plans.”
- convolvatron: “streaming is a really great base on which to build a distributed database that looks more like Postgres on top.”
- necubi: “I do think long term we’ll see some amount of streaming influence moving back into the batch systems.”