7 Databases in 7 Weeks for 2025

Original Article ↗ Hacker News Discussion ↗

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.