Yeah, but there are quite a few efforts out there to extend PG into a distributed DB of one flavor or another. Some examples are YugabyteDB, CockroachDB, Aurora and Citus. It's a reasonable approach, but it's also reasonable to come at it from the other direction - build a SQL engine on top of a solid distributed key-value store. Contrafactuals are always dicey, but FDB vanishing behind the Apple wall of silence sure didn't help.
> Some examples are YugabyteDB, CockroachDB, Aurora and Citus.
Of those the first two are not PG, they just share the wire protocol and try to be compatible at a SQL level. Aurora is not really distributed, it's replicated for availability and durability six ways at the block storage level. Citus is distributed as I understand it though.
> but it's also reasonable to come at it from the other direction - build a SQL engine on top of a solid distributed key-value store.
Sure, that's possible. I'm not talking about the wisdom of building your own relational database as the end goal, just that a distributed key value database and a SQL database don't have overlapping problem sets.
Sure quibble about the details. The point is, these are all attempts to make PG more scalable. Around the time these projects got started Foundation looked like abandonware. If it hadn't, it's possible that "how can we have really scalable SQL databases?" might have had Foundation as part of the answer.
Good point. Still, if FDB was high-profile proprietary software during this time it might have inspired an open source clone. Spanner inspired Cockroach and Yugabyte, after all.
CockroachDB is exactly this - a SQL engine on top of a distributed key value store. It is not an extension of Postgres itself, it just speaks the protocol and implements many of the features.
