3 ms·

Has Google contributed some of these changes back to Postgres? I went looking and even a search for "alloydb" in some postgres mailing lists return no results.

Has Google contributed some of these changes back to Postgres? I went looking and even a search for "alloydb" in some postgres mailing lists return no results. It has some very exciting features, I was a bit surprised to see nobody talking about it.

Cockbrand 4y ago
If I understand correctly, AlloyDB is a Postgres compatible re-implementation, so there's no shared code. So this is a bit like Wine compared to Windows, only with the big corp re-implementing the OSS software instead of the other way round.
- ppg677 4y ago
  You can't really be 100% postgres compatible without borrowing a lot of implementation
  - aeyes 4y ago
    Query and storage layer are nicely separated in the Postgres codebase, you can absolutely rip out the complete backend if you really want it. There is a Postgres interface to Spanner which probably did that.
- GabeWeiss_ 4y ago
  OMG no, we didn't reimplement Postgres. Definitely started from the PG kernel and made modifications from there.
  - Cockbrand 4y ago
    I often reference Cunningham‘s Law, and I’m glad it’s in full effect :) Thank you for the clarification!
GabeWeiss_ 4y ago
Not as of yet, no. I've gently nudged the eng/product teams in this direction, but for now it's all being kept in-house.
ellisv 4y ago
It's worrying that a lot of companies aren't pushing these types of changes back. Particularly with Google, they'll have software patents that prevent others from implementing the same improvements but also, based on their track record, will abandon this project within a few years. When that happens, their improvements will simply be inaccessible.
- GabeWeiss_ 4y ago
  I realize this may sound hollow coming from a Google employee...but I am fighting to be sure something like this stops happening (in particular the deprecating causing loss of functionality). Google is (a little) better than it has been in the past. E.g. the opening of the protocols on the Stadia controllers when Stadia was shut down so their controllers could work on other platforms. I am pushing at the OSS angle, but new product, so uphill battle. :)

Cockbrand 4y ago

If I understand correctly, AlloyDB is a Postgres compatible re-implementation, so there's no shared code. So this is a bit like Wine compared to Windows, only with the big corp re-implementing the OSS software instead of the other way round.

ppg677 4y ago
You can't really be 100% postgres compatible without borrowing a lot of implementation
- aeyes 4y ago
  Query and storage layer are nicely separated in the Postgres codebase, you can absolutely rip out the complete backend if you really want it. There is a Postgres interface to Spanner which probably did that.
GabeWeiss_ 4y ago
OMG no, we didn't reimplement Postgres. Definitely started from the PG kernel and made modifications from there.
- Cockbrand 4y ago
  I often reference Cunningham‘s Law, and I’m glad it’s in full effect :) Thank you for the clarification!

GabeWeiss_ 4y ago

Not as of yet, no. I've gently nudged the eng/product teams in this direction, but for now it's all being kept in-house.

ellisv 4y ago

It's worrying that a lot of companies aren't pushing these types of changes back. Particularly with Google, they'll have software patents that prevent others from implementing the same improvements but also, based on their track record, will abandon this project within a few years. When that happens, their improvements will simply be inaccessible.

GabeWeiss_ 4y ago
I realize this may sound hollow coming from a Google employee...but I am fighting to be sure something like this stops happening (in particular the deprecating causing loss of functionality). Google is (a little) better than it has been in the past. E.g. the opening of the protocols on the Stadia controllers when Stadia was shut down so their controllers could work on other platforms. I am pushing at the OSS angle, but new product, so uphill battle. :)