7 Databases in 7 Weeks for 2025

Original Article ↗ Hacker News Discussion ↗

Modern database choices are framed as long-term infrastructure bets, with many engineers favoring “boring,” battle-tested systems like PostgreSQL over trendier options that may flame out. Commenters highlight the rise of analytical engines such as DuckDB and ClickHouse, the underrated power of FoundationDB, and the common OLTP/OLAP pattern of pairing Postgres with a columnar store, while also weighing MySQL, Oracle, SQL Server, CockroachDB and various OLAP contenders like Apache Pinot. Vector databases and AI-focused storage are seen as promising but still too volatile, leading many to rely on extensions to existing databases until a clear, stable winner emerges.

Postgres and “boring” tech

  • Postgres is praised for extreme longevity and stability; people expect it to still be a safe choice decades from now.
  • Many prefer “boring” stacks (e.g., Postgres-based) to avoid database churn and hype cycles.
  • Some consider Oracle and SQL Server the pinnacle of boring RDBMSs, but their cost is seen as a major downside.

Commercial RDBMS (SQL Server, Oracle, DB2, etc.)

  • Historical reasons for SQL Server adoption: tight .NET integration, better tooling/drivers, and strong paid support.
  • Today, several commenters question its value proposition versus Postgres, except for features like Active Directory integration or specific enterprise support needs.
  • IBM’s DB2/IMS/Informix are mentioned as still around but mostly as legacy curiosities.

DuckDB and analytical tooling

  • DuckDB is repeatedly described as “having a moment” with strong DX, easy setup, and powerful features for local/desktop analytics and Parquet.
  • Used for quick experiments, Advent of Code in SQL, BI with Evidence.dev, and even ad‑hoc argument‑backing with built‑in visualization.
  • Limitations: only one concurrent writer, so not suited as a general server‑side OLTP replacement.
  • Comparisons arise with ClickHouse and chdb; DuckDB often preferred for integrations and extensions.

Vector / AI-oriented databases

  • Some readers expected an AI/vector DB; others note the space is volatile with many contenders (pgvector, VectorChord, Pinecone, etc.).
  • The article intentionally avoids picking a “winner” yet; preference is to wait for a stable, boring option.
  • Consensus that LLMs do not replace databases; relational algebra remains core, interfaces may change.

FoundationDB and other niche systems

  • FoundationDB is called “wildly underrated,” with admiration for its testing/simulation approach and proven large-scale deployments.
  • Barriers: hard to access for general developers, few “plug-and-play” higher-level layers; a few adapters (e.g., for Ecto) exist but ecosystem is thin.
  • Some wonder why no DynamoDB-compatible API has been built on FDB; others argue Dynamo/Cassandra/Scylla already cover that space well.

ClickHouse, Pinot, and OLAP stack choices

  • Many endorse a two‑DB strategy: Postgres for OLTP and ClickHouse for OLAP, citing real‑world success and operational ease.
  • Pinot advocates claim better architecture for real-time, user-facing analytics (segment-based scaling, star-tree pre-aggregation) and argue ClickHouse benchmarks underconfigure Pinot.
  • ClickHouse practitioners counter that sharding can be handled without downtime and that vertical scaling plus compression often avoid sharding entirely.
  • Pinot’s Java implementation sparks debate: some fear GC and tuning complexity; others note modern JVM collectors offer sub-millisecond pauses, with horizontal scaling offsetting throughput costs.

MySQL vs Postgres

  • Questions arise why MySQL is absent from the discussion given its use at large companies.
  • Points mentioned: historically better replication and connection handling for MySQL; stronger optimizer and MVCC story for Postgres; overall community and DBaaS ecosystem now tilt toward Postgres.
  • Uber’s migration from Postgres to MySQL is cited, but it’s unclear which arguments still hold.

Licensing, naming, and HA for Postgres/CockroachDB

  • CockroachDB’s relicensing is criticized; some now seek open Postgres-based HA instead.
  • Suggested Postgres HA stacks include Patroni, CloudNativePG, Stolon, and repmgr. One commenter flags Patroni issues; another notes it’s widely and successfully used and advises not to overthink it.
  • CockroachDB’s name itself is off-putting to some, despite the intended “disaster-resistant” metaphor.
  • There’s also debate over whether CockroachDB remains truly “open source” vs “source available.”

Graph and temporal/datolog databases

  • One commenter laments lack of new graph DBs; another dismisses pure graph databases like Neo4j as “toys” and prefers storing edges/vertices in relational or KV stores plus in-memory graph processing.
  • XTDB/“bitemporal” and Datalog are seen as niche but interesting; its upcoming v2 shifts to a SQL-first engine over the Postgres wire protocol, with an additional Datalog-like query language for continuity.

Vector DBs like Qdrant

  • Some ask why Qdrant or dedicated vector stores aren’t on the list; a reply argues that for database power-users, these are relatively uninteresting because many general DBs (including ones on the list) can handle vectors natively or via extensions, and dedicated vector DBs often lack broader features.