3 ms·

I’ll add to the positivity: this is the first time I’ve ever found a “we can do better than SQL” compelling. It’s easy to understand what it’s doing with a vari

I’ll add to the positivity: this is the first time I’ve ever found a “we can do better than SQL” compelling. It’s easy to understand what it’s doing with a variety of known quantities. It solves a difficult problem elegantly. It has 100% overlap with the goals I want it to have. It’s designed to be usable with minimal fuss. It does really a good job of portraying itself as magic (it will be awesome to use) without portraying itself as magic (it explains itself in terms of already knowable tools and how it leverages their strength). I do have a couple minor quibbles: - Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front. - Some of the language in this post are in CAP theorem territory but neglect to directly address that. I’d like to see how client usage compares with direct Postgres usage (idiomatic for each insofar as such a beast exists) in a Call Me Maybe. I know that’s a lot to ask in a 1.0 announcement four years in the making, but I hope it’s a priority to get this in front of Aphyr. Edit: oh and I definitely look forward to this being further distinguished from an ORM, because even though I can see the blue and black dress my mind keeps switching it back to gold and white.

RedCrowbar 5y ago
> I’ll add to the positivity Thank you! > Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front. We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)). EdgeDB tends to produce very short transactions, so that helps. EdgeDB also knows if your statements are read-only or not, so we have the ability to steer these into a read-only transaction, though this isn't implemented yet.
- eyelidlessness 5y ago
  It’s been a few years so this is pretty fuzzy (though I just jogged my memory re-reading the docs, which are consistent with my recollection)… there are two expenses: - The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those. - The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected by, the client. When automated by an abstraction layer, this can become pathological pretty easily depending on usage patterns. The most realistic alternatives are to provide a lower level abstraction (eg “I don’t want your guarantees, I want your errors”), or to provide other isolation options (eg “I don’t want your guarantees, I want my errors”). But there may well be opportunities here because EdgeDB knows as much as it does about the schema, and positions itself as a SQL replacement rather than a companion so it can potentially optimize for at least some of those cases at query time. That sounds complex enough to boggle my mind, but if y’all are up to it I’ll be excited to see how it goes!
  - RedCrowbar 5y ago
    The retry logic in clients is fully configurable, you can disable retries and get your TransactionSerializationError if you want that.
    - eyelidlessness 5y ago
      Awesome!
- eyelidlessness 5y ago
  Oof I meant to specifically address > We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)). You’ll likely not see anything noteworthy without specifically creating concurrency contention which specifically causes the kinds of pathological retry scenarios I mentioned. I’d be shocked if there isn’t at least a good starting point in either the Postgres test suite or Call Me Maybe. (Seriously though, I want to read Aphyr’s take on this project.)
- tylergetsay 5y ago
  Can I use this ability to direct the query to a read only replica or will EdgeDB handle this common scaling use case some other way?
  - RedCrowbar 5y ago
    Yes, the plan is to allow sending read-only queries to read replicas automatically. This isn’t implemented yet, but all the requisite pieces are there.
ninepoints 5y ago
I would suggest framing distributed systems analysis in terms of PACELC instead of CAP: https://en.wikipedia.org/wiki/PACELC_theorem https://en.wikipedia.org/wiki/PACELC_theorem

RedCrowbar 5y ago

> I’ll add to the positivity Thank you! > Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front. We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)). EdgeDB tends to produce very short transactions, so that helps. EdgeDB also knows if your statements are read-only or not, so we have the ability to steer these into a read-only transaction, though this isn't implemented yet.

eyelidlessness 5y ago
It’s been a few years so this is pretty fuzzy (though I just jogged my memory re-reading the docs, which are consistent with my recollection)… there are two expenses: - The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those. - The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected by, the client. When automated by an abstraction layer, this can become pathological pretty easily depending on usage patterns. The most realistic alternatives are to provide a lower level abstraction (eg “I don’t want your guarantees, I want your errors”), or to provide other isolation options (eg “I don’t want your guarantees, I want my errors”). But there may well be opportunities here because EdgeDB knows as much as it does about the schema, and positions itself as a SQL replacement rather than a companion so it can potentially optimize for at least some of those cases at query time. That sounds complex enough to boggle my mind, but if y’all are up to it I’ll be excited to see how it goes!
- RedCrowbar 5y ago
  The retry logic in clients is fully configurable, you can disable retries and get your TransactionSerializationError if you want that.
  - eyelidlessness 5y ago
    Awesome!
eyelidlessness 5y ago
Oof I meant to specifically address > We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)). You’ll likely not see anything noteworthy without specifically creating concurrency contention which specifically causes the kinds of pathological retry scenarios I mentioned. I’d be shocked if there isn’t at least a good starting point in either the Postgres test suite or Call Me Maybe. (Seriously though, I want to read Aphyr’s take on this project.)
tylergetsay 5y ago
Can I use this ability to direct the query to a read only replica or will EdgeDB handle this common scaling use case some other way?
- RedCrowbar 5y ago
  Yes, the plan is to allow sending read-only queries to read replicas automatically. This isn’t implemented yet, but all the requisite pieces are there.

ninepoints 5y ago

I would suggest framing distributed systems analysis in terms of PACELC instead of CAP: https://en.wikipedia.org/wiki/PACELC_theorem https://en.wikipedia.org/wiki/PACELC_theorem