bddicken

THIS++

pgBaseBackup seems very cool. It's great that they got support to continue building. We just don't use it presently.

Neki will support cross-shard ACID transactions with a combination of an external transaction coordinator and some changes to PostgreSQL itself to support this (either by engine modifications or extensions).

I expect as part of that, we'll allow users to leverage something similar to make sure that we don't get transaction tearing in backups.

Exactly. When you have a router + query parser in front of the db nodes, the burden of managing multiple versions simultaneously can be taken out of the app and into the database layer.

Broadly for Pg, minor version upgrades are straightforward as the data on disk is guaranteed to be compatible. All it takes is a restart or switchover to upgrade.

Major versions are more challenging for "vanilla" Postgres because that's not the case. Storage/catalog formats may change. There needs to be an explicit upgrade process for the data (eg, a database created with v18 won't work out of the box with v19).

The cool thing is, software like Neki (and Vitess for MySQL, which we maintain) have architectures that lend themselves to making this much more feasible. Because the actual database nodes sit behind a router + parser layer with Pg/MySQL compatibility, the upgrades can be done transparently to the user. We plan to write more about how this works in the future.

What I emphasized in this article (author here) is scaling postgres backups. This works because there's already rock-solid systems built into postgres + surrounding tooling to build from.

The broader takeaway is the principle of, "how do I take something that doesn't scale on its own and make it so?" This applies to backups, compute, storage layers, proxies. It's why Neki and Vitess are so powerful for everything from small 1GB databases to petabytes.

Hanging around to answer questions, too :)

Author here, thank you.

Technically, they are using js + gsap + svg embedded i the article with iframes.

Process-wise, I drafted most of them as static images in excalidraw, passed the images along to cursor for a first draft, applied styling rules, and then did a bunch of fine-tuning.

Very welcome

We have tons of customers who do exactly this. It's great. Sharding is for customers who out grow this path.

You should read through those articles.

> So an extreme example is OpenAI needing 50 replicas, but we're doing five blades ... err, we're doing 768 servers because the need arose "pretty quickly"?

If you read the OpenAI article, you'll see that they actually used sharding to offload a bunch of work from their "1 primary 50 replicas setup"

>>> "To mitigate these limitations and reduce write pressure, we’ve migrated, and continue to migrate, shardable (i.e. workloads that can be horizontally partitioned), write-heavy workloads to sharded systems such as Azure Cosmos DB..."

The 768 servers and 1PB example is just one of many configurations. A business with 10TB may choose to go from a monolithic database to a 8-shard setup to improve backup times, eliminate single-point-of-failure, have more breathing room for scaling.

Hey, author here.

Technically, they're powered by js + gsap + svg.

Process wise (for most of them) I sketched them out in advance in excalidraw for figure out layout, then passed these along to cursor to have it build out an initial draft from the image, then used some styling rules to get all the styles inline, then did a bunch of fine-tuning.