Talks to Watch

Michael Stonebraker | Big Data is (at least) Four Different Problems

30K views · Dec 4, 2015 · 55:53 · 5 HN recommenders · 7 mentions · discussed 2015–2024

Database pioneer Michael Stonebraker argues that 'big data' is really at least four different problems: big volumes with small analytics, big analytics, velocity, and variety. He comments on where each market is heading.

Why Hacker News points people here: HN points to it as a thoughtful, first-principles take from a Turing award winner that cuts through NoSQL and big data hype.

“a rather interesting talk by a very thoughtful Turing award winning engineer named Michael Stonebraker”HN comment, 2017

What Hacker News said 7

Strongly recommendsedejongAug 2017

“a rather interesting talk by a very thoughtful Turing award winning engineer named Michael Stonebraker”

Thoughtful critique of NoSQL hype by Turing award winner

Full comment

Whenever I see a young gullible engineer, all twinkly-eyed and bedazzled by the MongoDB hype (or any other NoSQL hype), I'll send him a link [1] on a rather interesting talk by a very thoughtful Turing award winning engineer named Michael Stonebraker. It takes a couple of days for the charm of NoSQL to wane off, but eventually they'll always see how they have been fooled into believing without a sane level of critique. [1] this video

in “The Marketing Behind MongoDB” · view on HN
Strongly recommendsvishnuguptaMay 2024

“Highly recommend this and related talks by him, most of them are in YouTube.”

Origin of the 3 V's from a DBMS legend's talk

Full comment

I first heard of this 3 V's in a Michael Stonebreaker's talk[1]. For the uninitiated he's a legend in DBMS space, Turing award winner[2]. Highly recommend this and related talks by him, most of them are in YouTube. [1] this video [2] link

RecommendsmattsteDec 2015

“Definitely worth a watch.”

Stonebraker talk on where databases are headed

Full comment

Stonebraker recently gave a talk at my school on where he thinks databases are headed in the future[0]. Definitely worth a watch. [0] this video

in “Readings in Database Systems, 5th Edition” · view on HN
RecommendsjasodeApr 2016

“I think a better presentation to flesh out these ideas is the following youtube video”

Better presentation of Stonebraker's views on SQL and ACID

Full comment

Yes, that slide deck in isolation looks an ad so it's probably better to get some background on Michael Stonebraker's "big picture" beliefs and core premises: ++ He believes SQL is the "right" and most proven access model. (Note that SQL does not mean RDBMS like Oracle/MSSQL.) ++ He believes in ACID ++ He believes that other db engines' (NoSQL, etc) approaches to gain speed and scaling of clusters by sacrificing SQL and ACID is wrong and his proof is that those other products end up eventually bolting on SQL and ACID anyway. I think a better presentation to flesh out these ideas is the following youtube video: this video It's 55 minutes long so to save time, HN readers may prefer to browse it by pressing "L" key to step through it quickly. Just read the slides shown behind him and if the bullet points look interesting, rewind and listen to his presentation. One can dwell on those SQL/ACID merits in isolation and consider separately, the question of whether VoltDB-as-a-product fulfills those ideals.

in “Urban Myths about SQL (2015)” · view on HN
RecommendswencJun 2020

“I enjoyed his talk on "Why Big Data is at least 4 different problems”

Enjoyable talk by an opinionated, first-principles database pioneer

Full comment

I read the Red Book when I was figuring out data architectures for my company. (the other book was Designing Data-Intensive Archictures by Martin Kleppmann) Stonebraker et al are very opinionated (especially about SQL and relational databases), but in a way I can accept because a lot of his thinking is based on first-principles. Stonebraker also has a string of database successes (Ingres, Postgres, Vertica etc.) which gives him enough street cred to prove he's not just spewing theory from an ivory tower. He's not necessarily correct in every opinion, but his opinions are interesting and worth considering. I enjoyed his talk on "Why Big Data is at least 4 different problems" this video

in “Making Databases Work: The Pragmatic Wisdom of Michael Stonebraker (2018)” · view on HN
Cites itelvinyungDec 2017

“Mike Stonebraker says that there are no fast distributed transactions”

Source for claim that fast distributed transactions do not exist

Full comment

Whether that actually matters is arguable: No one has performant distributed (i.e. cross-partition) ACID. (Except maybe Google.) For the thing that does matter, which is ACID within the same partition/entity group, I would argue that RethinkDB already does have that. Mike Stonebraker says that there are no fast distributed transactions [1]. I'm inclined to believe him, and that's not just an appeal to authority. [1] this video

in ““Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB” · view on HN
Cites itrefsetSep 2023

Stonebraker talk cited alongside one-size-fits-all database argument

Full comment

Firstly, disclosure: I work on XTDB, where we are in the process of building out a new columnar SQL engine that also (still) supports edn-flavoured Datalog, see link Perhaps the most fundamental aspect here is the inherent tension between (A) typical columnar relational schemas which primarily target efficient OLAP across very wide & sparse tables, and (B) the nature of 'graph' systems (whether OLAP or OLTP) which tend towards handling a huge number of tables and/or recursive self-joins + incremental view maintenance. I believe Michael Stonebraker's conjecture continues to be that a "one size fits all" database engine is essentially unachievable, and therefore you can't expect a single database system to be competitive across both domains simultaneously. However some databases (SQL Server springs to mind) are apparently pretty good at running multiple engines in parallel. With the v2 XTDB engine design we are sacrificing some of our graph capabilities in the short term (WCOJ and self-join optimisations) for what we feel are more pressing advantages of the columnar model (low-cost retention of history and vectorized processing). We are also aiming to retain reasonable OLTP performance as well, in a similar vein to SingleStore etc., since the target audience is still application developers rather than data analysts. If you are looking for a way of using Datalog on existing columnar storage engines today, you should definitely look at link Also, this Stonebraker talk on "Big

in “Fast Analytics and Graph Traversals with Datalog” · view on HN