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

Yep! https://vitess.io/docs/reference/features/distributed-transa...

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

A lot of what you're referring to is dictated by the sharding strategy. Vitess and Neki both let you configure this via the VSchema / data topology (That's what I'm getting at here)

https://planetscale.com/blog/making-768-servers-look-like-1#...

This decision matters a ton. I drilled into this specific point on sharding in one of my articles from awhile back:

https://planetscale.com/blog/database-sharding

This is something you face any time you shard data, no matter the system. Single-shard queries are preferred to cross-shard ones. We want 99% of what we do to be single shard, but occasionally cross-shard work is unavoidable.

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.

Spreading requests out across hundreds, thousands, and in some cases even more is precisely what is done in the industry for big databases! Good examples:

cashapp: https://code.cash.app/planetscale-metal github: https://github.blog/engineering/infrastructure/partitioning-... etsy: https://www.etsy.com/codeascraft/migrating-etsyas-database-s...

These companies could not realistically operate off a single database server.

Caching at all levels is key to good db performance (cpu cache <-> ram <-> disk). CPU cache optimization is not my area of expertise, but I did write another fun article on io devices and how it related to databsae perf:

https://planetscale.com/blog/io-devices-and-latency

Network saturation, and just resource saturation broadly, is a huge reason to shard. If/When the network, cpu, or disk for a subset of shards becomes a bottleneck, add more shards.

Hey, I wrote this!

Sharding is cool and foundational to making the internet work. I'm around to answer Qs.

It may not have the popularity it once did, but MySQL still powers a huge % of the internet.

What about spanner specifically benefits from random ids over sequential ones?

Simple sequential IDs are great. If you want UUID, v7 is the way to go since it maintains sequential ordering.

+1

I've also written about sharding.

https://planetscale.com/blog/database-sharding

B+trees combined with sequential IDs are great for writes. This is because we are essentially just appending new rows to the "linked list" at the bottom level of the tree. We can also keep a high fill % if we know there isn't a lot of data churn.

If you're sharding based purely on sequential ID ranges, then yes this is a problem. Its better practice to shard based on a hash of your ID, so sequential id assignments turn into non-sequential shard keys, keeping things evenly distributed.

It's really just a matter of tradeoffs. B-trees are great, but are better suited for high read % and medium/low write volume. In the opposite case, things like LSMs are typically better suited.

If you want a comprehensive resource, I'd recommend reading either Designing Data Intensive Applications (Kleppman) or Database Internals (Petrov). Both have chapters on B-trees and LSMs.

I've read this paper and it's a neat idea. It hasn't been introduced into popular oss databases like postgres and mysql, and my understanding is it has some drawbacks for real prod use vs ths simplistic benchmarks presented in the paper.

Would love to know if anyones built something using it outside of academic testing.

Oh hey, I wrote this! Happy to chat more about the article here. Databases are kinda my thing.

epic

Yep. Its a wonderful capability to have for some situations, but for 90% of applications SERIALIZABLE isolation is overkill.

These are still transactions! It's not uncommon for a large % of transactions in an OLTP workload to be only one query without explicit BEGIN / COMMIT; This is called an autocommit transactions or implicit transaction.

Thanks, fixed!