5 ms·

It's unfortunate that they went silent for years after the Apple acquisition. That period was key for database adoption. I have the feeling everybody kind of se

It's unfortunate that they went silent for years after the Apple acquisition. That period was key for database adoption. I have the feeling everybody kind of settled for pgsql.

eloff 5y ago
Those are two completely non overlapping use cases. If you can use pgsql for your problem, you have no business trying to use a distributed key value store instead. That would be at least as dumb as driving screws with a hammer.
- cwp 5y ago
  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.
  - eloff 5y ago
    > 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.
    - cwp 5y ago
      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.
      - jen20 5y ago
        FoundationDB was proprietary software before the acquisition, and not open source, so I’d say close to “no chance”.
        cwp 5y ago
        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.
    - qaq 5y ago
      Yugobyte is slightly altered PG "Frontend" with custom storage backend
  - jen20 5y ago
    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.
threeseed 5y ago
> I have the feeling everybody kind of settled for pgsql. That's probably because of spending time on this echo chamber. In reality everyone has likely been staying with the same databases they know and love but just moved to the cloud. It's why now AWS for example offers such a wide variety of databases e.g. MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, Cassandra, Redis.

It's unfortunate that they went silent for years after the Apple acquisition. That period was key for database adoption. I have the feeling everybody kind of settled for pgsql.

eloff 5y ago

Those are two completely non overlapping use cases. If you can use pgsql for your problem, you have no business trying to use a distributed key value store instead. That would be at least as dumb as driving screws with a hammer.

cwp 5y ago
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.
- eloff 5y ago
  > 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.
  - cwp 5y ago
    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.
    - jen20 5y ago
      FoundationDB was proprietary software before the acquisition, and not open source, so I’d say close to “no chance”.
      - cwp 5y ago
        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.
  - qaq 5y ago
    Yugobyte is slightly altered PG "Frontend" with custom storage backend
- jen20 5y ago
  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.

threeseed 5y ago

> I have the feeling everybody kind of settled for pgsql. That's probably because of spending time on this echo chamber. In reality everyone has likely been staying with the same databases they know and love but just moved to the cloud. It's why now AWS for example offers such a wide variety of databases e.g. MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, Cassandra, Redis.