Databases in 2024: A Year in Review

Original Article ↗ Hacker News Discussion ↗

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).