5 ms·

It reminds me of Yugabyte, which is Postgres compatible > YugabyteDB is the open source, distributed SQL database for global, internet- scale applications with

by mkl95 5y ago

It reminds me of Yugabyte, which is Postgres compatible > YugabyteDB is the open source, distributed SQL database for global, internet- scale applications with low query latency, extreme resilience against failures. * However Fly is nicer from a developer's point of view, because it doesn't require you to learn a new query language, you can write good old Postgres. * https://www.yugabyte.com/ https://www.yugabyte.com/

qaq 5y ago
What new query language do you need to learn for yugabyte ?
- mkl95 5y ago
  YSQL. From their docs: > Successive YugabyteDB releases honor PostgreSQL syntax and semantics, although some features (for example those that are specific to the PostgreSQL monolithic SQL database architecture) might not be supported for distributed SQL. The YSQL documentation specifies the supported syntax and extensions. It is psql compatible, but you may run into missing features, so you will have to find a way around that. The documentation says that their latest release is based on psql 11.2, and psql 14 will be released soon.
rad_gruchalski 5y ago
Yugabyte with replica placement and tablespaces does this for free without having to do any try / catch.
- tptacek 5y ago
  All the next-gen distributed SQL databases are neat. We are definitely not trying to compete with them; that's not at all where we're heading (though we'd be happy to work with them to bring their databases to our platform). This is just a neat hack you can do with totally standard Postgres. It's a thing other people do outside of Fly; we just like how easy you can make it if you can program both the CDN and the applications.
- mrkurt 5y ago
  We observed two things from developers when we started working on this: 1. The first thing we did was give them CockroachDB. Modeling data for geo distributed Cockroach is conceptually similar to yugabyte. It's not easy, though, to do that modeling. For read heavy apps most devs didn't want to do the work. 2. We also experimented with cross regions writes at the DB level (both with Postgres and Cockroach). The failure cases on those were bad. Apps are pretty naive about queries, so interleaving writes with >10ms of latency between reads resulted in really slow requests. These were pretty frequent! Most apps broke if the devs didn't carefully optimize that sequence. The free we're going for here is "free for most developers". Changing a data model or optimizing how an app talks to a database wasn't quite free enough for our purposes, and neither were necessary for the types of workloads most people deal with. They _definitely_ need to use something that's not-just-postgres to do multi region writes or distribute write heavy workloads. That's why we wrote the whole section on graduating to Cockroach. Graduating from Postgres to yugabyte also works!
  - rad_gruchalski 5y ago
    Never touched cockroach because of their license but have hands on experience with yugabyte. Creating geo distributed data layer is basically: create tablespace with replica placement, create table with tablespace, give the role explicit access to a single talespace Yugabyte does everything else. It’s all standard sql with a couple of extra keywords.
    - mrkurt 5y ago
      We're talking about a different level of "easy" I think. Easy: asking devs add a gem to their app. Hard: asking them to write migration code of any kind, much less understand tablespaces and replica placement. You're advocating something we spent a lot of time trying! Boring Postgres read replicas worked for almost everyone we worked with, and it works for the vast majority of what full stack folks are already building. Our infrastructure will work great for the ones who need Cockroach/Yugabyte, too! That's specifically why we covered it in our post. :)
      - 5y ago

by mkl95 5y ago

qaq 5y ago

What new query language do you need to learn for yugabyte ?

mkl95 5y ago
YSQL. From their docs: > Successive YugabyteDB releases honor PostgreSQL syntax and semantics, although some features (for example those that are specific to the PostgreSQL monolithic SQL database architecture) might not be supported for distributed SQL. The YSQL documentation specifies the supported syntax and extensions. It is psql compatible, but you may run into missing features, so you will have to find a way around that. The documentation says that their latest release is based on psql 11.2, and psql 14 will be released soon.

rad_gruchalski 5y ago

Yugabyte with replica placement and tablespaces does this for free without having to do any try / catch.

tptacek 5y ago
All the next-gen distributed SQL databases are neat. We are definitely not trying to compete with them; that's not at all where we're heading (though we'd be happy to work with them to bring their databases to our platform). This is just a neat hack you can do with totally standard Postgres. It's a thing other people do outside of Fly; we just like how easy you can make it if you can program both the CDN and the applications.
mrkurt 5y ago
We observed two things from developers when we started working on this: 1. The first thing we did was give them CockroachDB. Modeling data for geo distributed Cockroach is conceptually similar to yugabyte. It's not easy, though, to do that modeling. For read heavy apps most devs didn't want to do the work. 2. We also experimented with cross regions writes at the DB level (both with Postgres and Cockroach). The failure cases on those were bad. Apps are pretty naive about queries, so interleaving writes with >10ms of latency between reads resulted in really slow requests. These were pretty frequent! Most apps broke if the devs didn't carefully optimize that sequence. The free we're going for here is "free for most developers". Changing a data model or optimizing how an app talks to a database wasn't quite free enough for our purposes, and neither were necessary for the types of workloads most people deal with. They _definitely_ need to use something that's not-just-postgres to do multi region writes or distribute write heavy workloads. That's why we wrote the whole section on graduating to Cockroach. Graduating from Postgres to yugabyte also works!
- rad_gruchalski 5y ago
  Never touched cockroach because of their license but have hands on experience with yugabyte. Creating geo distributed data layer is basically: create tablespace with replica placement, create table with tablespace, give the role explicit access to a single talespace Yugabyte does everything else. It’s all standard sql with a couple of extra keywords.
  - mrkurt 5y ago
    We're talking about a different level of "easy" I think. Easy: asking devs add a gem to their app. Hard: asking them to write migration code of any kind, much less understand tablespaces and replica placement. You're advocating something we spent a lot of time trying! Boring Postgres read replicas worked for almost everyone we worked with, and it works for the vast majority of what full stack folks are already building. Our infrastructure will work great for the ones who need Cockroach/Yugabyte, too! That's specifically why we covered it in our post. :)
    - 5y ago