7 ms·
(NB: Post author here) We don't have many Haskell programmers, we mostly work in Rust, C and Go, but we're always open to new things... This is pretty Postgre
by djk447 5y ago
(NB: Post author here)
We don't have many Haskell programmers, we mostly work in Rust, C and Go, but we're always open to new things...
This is pretty Postgres specific. From the beginning Postgres has focused on extensibility and allowed this sort of stuff with custom functions/operators/types. Many other SQL variants don't have that. It's one of the main things that sets Postgres apart from other databases, see Stonebreaker's great history of this, specifically the stuff on Object Relational databases [1].
We're pretty focused on building on top of Postgres because of that functionality. We do have some other stuff to make Postgres more scalable, and you're welcome to try us out, but if there's something specific that BigQuery offers that you need feel free to file a github issue around that too. But yeah, no plans to do things like this in other databases, they just don't have the infrastructure...
[1]:https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/papers/SH05.pdf https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/pape...
- akulkarni 5y ago(TimescaleDB co-founder) Agree - what would you need to see in PostgreSQL / TimescaleDB to enable you to switch from Big Query? We are all ears :-)
- methyl 5y agoNot the op, but infinite scalability without any infrastructure work required besides loading the data is what holds me on BigQuery
- akulkarni 5y agoThanks for sharing. "infinite scalability" is something we are aiming for in our new vision for Timescale Cloud: https://blog.timescale.com/blog/announcing-the-new-timescale-cloud-and-a-new-vision-for-the-future-of-database-services-in-the-cloud/ https://blog.timescale.com/blog/announcing-the-new-timescale... We are not there today, but we are making progress. Any other feedback - please let us know :-)