Hacker News: franckpachot

New comment by franckpachot in "Go ahead, self-host Postgres"

franckpachot — Sat, 20 Dec 2025 17:10:29 +0000

Beyond the hype, the PostgreSQL community is aware of the lack of "batteries-included" HA. This discussion on the idea of a Built-in Raft replication mentions MongoDB as:

>> "God Send". Everything just worked. Replication was as reliable as one could imagine. It outlives several hardware incidents without manual intervention. It allowed cluster maintenance (software and hardware upgrades) without application downtime. I really dream PostgreSQL will be as reliable as MongoDB without need of external services.

https://www.postgresql.org/message-id/0e01fb4d-f8ea-4ca9-8c9...

New comment by franckpachot in "Go ahead, self-host Postgres"

franckpachot — Sat, 20 Dec 2025 17:04:26 +0000

Be sure to read the Муths and Truths about Synchronous Replication in PostgreSQL (by the author of Patroni) before considering those solutions as cloud-native high availability: https://www.postgresql.eu/events/pgconfde2025/sessions/sessi...

New comment by franckpachot in "Go ahead, self-host Postgres"

franckpachot — Sat, 20 Dec 2025 17:01:53 +0000

CloudNativePG is automation around PostgreSQL, not "batteries included", and not the idea of Kubernetes where pods can die or spawn without impacting the availability. Unfortunately, naming it Cloud Native doesn't transform a monolithic database to an elastic cluster

New comment by franckpachot in "Go ahead, self-host Postgres"

franckpachot — Sat, 20 Dec 2025 16:55:50 +0000

It's largely cultural. In the SQL world, people are used to accepting the absence of real HA (resilience to failure, where transactions continue without interruption) and instead rely on fast DR (stop the service, recover, check for data loss, start the service). In practice, this means that all connections are rolled back, clients must reconnect to a replica known to be in synchronous commit, and everything restarts with a cold cache.

Yet they still call it HA because there's nothing else. Even a planned shutdown of the primary to patch the OS results in downtime, as all connections are terminated. The situation is even worse for major database upgrades: stop the application, upgrade the database, deploy a new release of the app because some features are not compatible between versions, test, re-analyze the tables, reopen the database, and only then can users resume work.

Everything in SQL/RDBMS was thought for a single-node instance, not including replicas. It's not HA because there can be only one read-write instance at a time. They even claim to be more ACID than MongoDB, but the ACID properties are guaranteed only on a single node.

One exception is Oracle RAC, but PostgreSQL has nothing like that. Some forks, like YugabyteDB, provide real HA with most PostgreSQL features.

About the hype: many applications that run on PostgreSQL accept hours of downtime, planned or unplanned. Those who run larger, more critical applications on PostgreSQL are big companies with many expert DBAs who can handle the complexity of database automation. And use logical replication for upgrades. But no solution offers both low operational complexity and high availability that can be comparable to MongoDB

Rethinking Data Integrity: Why Domain-Driven Design Is Crucial

franckpachot — Fri, 12 Dec 2025 23:02:54 +0000

Article URL: https://thenewstack.io/rethinking-data-integrity-why-domain-driven-design-is-crucial/

Comments URL: https://news.ycombinator.com/item?id=46250117

Points: 2

# Comments: 0

New comment by franckpachot in "PostgreSQL, MongoDB, and what "cannot scale" means"

franckpachot — Mon, 08 Dec 2025 21:42:24 +0000

What about "cannot scale without downtime"? While all databases can scale vertically, increasing or decreasing CPU or memory resources requires a restart, which leads to downtime. All sessions must disconnect, the system restarts, and users reconnect and execute their first queries with a cold cache. This is far from ideal, especially when workload spikes—the very situation where scaling up is needed. Cloud-native databases that promote scalability typically scale horizontally without downtime. This involves adding or removing nodes and automatically resharding data without stopping the application. Such elasticity is key to the cost efficiency in the cloud: it lets you scale resources up or down with the workload, avoiding excess provisioning.

Why 'Store Together, Access Together' Matters for Your Database

franckpachot — Mon, 17 Nov 2025 21:20:36 +0000

Article URL: https://thenewstack.io/why-store-together-access-together-matters-for-your-database/

Comments URL: https://news.ycombinator.com/item?id=45958465

Points: 1

# Comments: 0

New comment by franckpachot in "ClickHouse vs PostgreSQL UPDATE performance comparison"

franckpachot — Wed, 20 Aug 2025 18:16:03 +0000

What is the null join behavior that cause you problem?

New comment by franckpachot in "Neki – Sharded Postgres by the team behind Vitess"

franckpachot — Wed, 13 Aug 2025 05:07:29 +0000

The companies that attempt to replace PostgreSQL do so not to replace PostgreSQL itself, but to replace Oracle.

New comment by franckpachot in "Postgres LISTEN/NOTIFY does not scale"

franckpachot — Thu, 10 Jul 2025 21:26:45 +0000

Can you provide more details? Inserting with unique indexes do not lock the table. Case statements are ok in where clause, use expression indexes to index it

New comment by franckpachot in "[dead]"

franckpachot — Thu, 29 May 2025 19:37:58 +0000

A Data Council talk on the modern SQL vs NoSQL

New comment by franckpachot in "Jepsen: Amazon RDS for PostgreSQL 17.4"

franckpachot — Wed, 30 Apr 2025 13:26:30 +0000

The Write-Ahead Logging (WAL) is single-threaded and maintains consistency at a specific point in time in each instance. However, there can be anomalies between two instances. This behavior is expected because the RDS Multi-AZ cluster does not wait for changes to be applied in the shared buffers. It only waits for the WAL to sync. This is similar to the behavior of PostgreSQL when synchronous_commit is set to on. Nothing unexpected.

New comment by franckpachot in "[dead]"

franckpachot — Thu, 03 Apr 2025 17:56:35 +0000

Do you declare your Foreign Key in your SQL database? What about MongoDB?

New comment by franckpachot in "[dead]"

franckpachot — Sun, 12 Jan 2025 22:36:47 +0000

Are NULLs treated as distinct or duplicates in your UNIQUE INDEX? It depends SQL != NoSQL != some specific implementations Which option offers the best developer experience? Comments welcome

New comment by franckpachot in "PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni"

franckpachot — Mon, 09 Dec 2024 22:34:03 +0000

YugabyteDB supports much more than basic things. I've been a 3+ years dev advocate for Yugabyte, and I've always seen triggers. LISTEN/NOTIFY is not yet there (it is an anti-pattern for horizontal scalability, but we will add it as some frameworks use it). Not yet 100% compatible, but there's no Distributed SQL with more PG compatibility. Many (Spanner, CRDB, DSQL) are only wire protocol + dialect. YugabyteDB runs Postgres code and provides the same behavior (locks, isolation levels, datatype arithmetic...)

New comment by franckpachot in "PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni"

franckpachot — Mon, 09 Dec 2024 21:57:22 +0000

Index creation should not be controlled by statement timeout, but backfill_index_client_rpc_timeout_ms which defaults to 24 hours. May have been lower in old versions

New comment by franckpachot in "B-Trees and Database Indexes"

franckpachot — Wed, 11 Sep 2024 06:43:23 +0000

It depends on the use cases and performance goals. You may want to distribute the rows that you insert, and then a random UUID makes sense. However, it is too much distributed for B-Tree indexes and the problem is not only cache but the amount of modifications due to leaf block splits. This includes MySQL which stores the primary key in a B-Tree index. Other use cases may benefit from colocating the rows that are inserted together. Think of timeseries, or simply an order entry where you query the recent orders. A sequence makes sense there, to have a good correlation between the index (on time) and the primary key. This avoids too many random reads with low cache hits.

It is wrong to think that distributed databases do not need sequences. YugabyteDB allows it. With YugabyteDB you use hash sharding to distribute them to a small number of hash ranges, so that they don0t go all at the same place, but are not scattered across the whole database. CockroachDB and Spanner doesn't have hash sharding and that's why they do not recommend sequences. There are also use cases where range sharding on the sequence is good when you don't need to distribute the data ingest, but benefit from their colocation when querying.

New comment by franckpachot in "What Is the Open Source Alternative to CockroachDB?"

franckpachot — Wed, 28 Aug 2024 20:52:09 +0000

1. Regarding performance, I recently did a simple test. CockroachDB uses a considerable number of CPU instructions compared to YugabyteDB: https://dev.to/yugabyte/comparing-sql-engines-by-cpu-instruc...

Writing a database from scratch is not easy. YugabyteDB uses some PostgreSQL, Kudu, and RocksDB code that has been heavily optimized before. Those are good codebases, and only some parts need to be enhanced to make them distributed.

2. Their Go version of RocksDB, Peeble, seems less efficient. They did it for a good reason. They didn't have the C++ skills to enhance RocksDB itself.

3. The repo holds more than the database.

C: is the SQL layer, based on PostgreSQL

C++: the transactional distributed storage, heavily modified Kudu and RocksDB

Java: some regression tests, the managed service automation, sample applications

TS: the Graphical User Interface

Python: some tooling to build the releases, some support tools

The database itself is C and C++

New comment by franckpachot in "CockroachDB license change"

franckpachot — Fri, 16 Aug 2024 20:34:10 +0000

YugabyteDB is and will always be Apache2. It is PostgreSQL compatible (the query layer is a fork of PostgreSQL) so the migration from CockroachDB, which implements a subset of PostgreSQL features, is easy.

How to Enhance Database Performance Testing Using Custom SQL Scripts in PgBench

franckpachot — Wed, 01 May 2024 08:56:32 +0000

Article URL: https://www.yugabyte.com/blog/pgbench-custom-sql-scripts/

Comments URL: https://news.ycombinator.com/item?id=40220982

Points: 10

# Comments: 0