Databases in 2024: A Year in Review

Original Article ↗ Hacker News Discussion ↗

A widely read annual “databases in 2024” retrospective from a CMU database group sparks strong reactions: readers praise its style and breadth while pushing back hard on its harsh take on Redis and non‑SQL data models. Commenters debate the enduring dominance and shortcomings of SQL, the role of specialized systems like Redis, DuckDB, and graph databases, and how license changes and cloud offerings are reshaping the open‑source ecosystem. Threaded through is a sense that database startups face brutal economics—illustrated by the shutdown of a well‑funded tuning company—and that “boring” workhorse systems like Postgres and SQL Server remain central despite the hype around newer engines.

Tone and Style of the Review

  • Many readers enjoy the humorous, irreverent style and pop-culture/celebrity tangents; others find it bombastic, overly focused on drama and fundraising, and light on technical depth in places.
  • The recurring jokes about a certain Oracle billionaire are widely read as satire, though some find the “fawning” or amount of space spent on him odd or irrelevant.

Redis, SQL, and Data Models

  • A large subthread debates criticism of Redis’s API and type system from the linked video.
  • Critics of the video say it misunderstands Redis’s “data-structure server” model, over-indexes on “it’s not SQL,” and ignores powerful features (sorted sets, probabilistic structures, queues, leaderboards, real-time use cases).
  • Defenders summarize the criticisms as: inconsistent commands by type, dynamic typing on keys, and “fake” transactions via MULTI/EXEC.
  • Further debate covers whether Redis’s semantics resemble a dynamically typed global-variable store vs. statically typed SQL schemas.
  • Performance claims are contested: one side calls Redis “slow” due to single-threading and network hops; others say it’s more than fast enough for its niche and point to alternatives (Dragonfly, Garnet).

SQL’s Dominance and Alternatives

  • Multiple comments agree with the article’s “SQL is king” framing but note SQL’s ergonomic flaws and limited recursion.
  • Some argue that non-relational data models warrant non-SQL languages and that not all roads lead back to SQL. Others counter that many non-SQL systems eventually add SQL layers.
  • There’s appreciation for new query languages (e.g., PRQL, Datalog variants) but skepticism about their adoption barriers.

Major Vendors and SQL Server

  • Several note the article largely ignores SQL Server and other classic enterprise DBs (Oracle, DB2, Teradata, etc.).
  • Opinions on SQL Server: technically strong, “boringly reliable,” with excellent tooling and OLAP/ETL/reporting stack, but increasingly sidelined by licensing cost and the rise of Postgres/MySQL.
  • Disagreement over scalability: some say it scales fine; others claim Oracle scales better at true company-wide scale.

Startups, OtterTune, and Licensing Drama

  • Readers are struck by how a well-funded, well-credentialed optimization startup died quickly, reinforcing how hard DB startups are.
  • There’s curiosity (and some criticism) around the story of a failed acquisition by a private-equity-backed Postgres company and the resulting informal “ban” on that firm recruiting from a university group; some see that as fair warning to students, others as questionable.
  • The broader license-change section sparks discussion about why Redis/Elasticsearch triggered forks but MongoDB/Neo4j/Cockroach/Confluent Kafka didn’t; commenters cite original license choice, size of contributor communities, and real-world impact.
  • ScyllaDB’s license shift is noted as practically unforkable due to codebase complexity and contributor scarcity.

Other Systems and Ecosystem Notes

  • DuckDB is widely praised as a “shove it everywhere” analytics engine, though a few report stability issues and slow bug triage.
  • Graph vs. relational: newer relational systems (Umbra, CedarDB) tout strong graph workloads; commenters note that good planners/compilers narrow the gap, with graph DBs mainly winning on extreme traversals.
  • Greenplum’s trajectory and the Cloudberry fork (now Apache) are discussed as examples of open vs. closed evolution.

Cloud vs. Self‑Managed and Cost

  • Several comments explore when self-managed databases beat cloud DBaaS economically; anecdotes suggest the crossover can be very early for some teams.
  • There’s skepticism of high-priced cloud warehouses (e.g., Snowflake) versus cheaper, mixed stacks (DuckDB, Iceberg/Hudi, S3 tables, Vertica, Ocient, Yellowbrick).