3 ms·

Really nicely done beta page, and the product is something that's needed to exist for a long time now. I remember talking with the RethinkDB guys before they c

Really nicely done beta page, and the product is something that's needed to exist for a long time now. I remember talking with the RethinkDB guys before they closed and being worried they were making a bad decision not getting a cloud service in place earlier, so good on doing that. I have two points of feedback: 1. How open source is it? I didn't get a great feel from the beta page, but will you make it as easy as setting up a docker container or helm chart? I'd suggest that if you want to align incentives as best as possible, consider one of those new-fangled OSS licenses that has the most recent updates closed-source, then auto-open sourcing after a time period. That way you can give away a really nice, well-packaged version for free, not worry about Amazon, and still capture a big chunk of revenue from bigger clients who need the newest. 2. What are your plans/thoughts on denormalization [0]? Liron is a friend of mine and we've had interesting discussions on this since way back, I'd encourage you all to reach out to him, and consider it strongly. The "holy grail" for many years now has been obvious: a subscribable DB engine that handles denormalization. I hope you guys achieve it. Good luck! [0] https://lironshapira.medium.com/data-denormalization-is-broken-7b697352f405 https://lironshapira.medium.com/data-denormalization-is-brok...

kiwicopple 6y ago
These are great questions. > will you make it as easy as setting up a docker container or helm chart? Yes, likely docker-compose in the short term (for our "local emulator"), and then something more prod-friendly later. Licensing is always a tough decision - we build client libraries for every tool we use, which are MIT licensed. Tools we build ourselves (like the Realtime server), are licensed under Apache 2.0. As you point out, we've started with our hosted platform because we feel this is important (as a business). This par is not yet public (also for security) and we may have to license it with a BSD license when we do open source it. > a subscribable DB engine that handles denormalization One of my favourite topics, and something we've been thinking about for months. It's incredibly hard to solve, especially when you add in Row Level Security and conflict resolution. Our current thinking is some sort of client store, using CRDTs that infer types from the database. We have some ideas for this but it's very early days. I'd love to talk to Liron - I'll reach out.
- robertlagrant 6y ago
  Just make sure cloud companies can't just host your solution and make easy money from it. The Timescale licence is worth a look.
- sixdimensional 6y ago
  I like the direction you guys seem to be taking here with Supabase. Regarding the comment about subscription-based DB engine and denormalization, I posted this [1] on the post about Materialize although I don't think anyone read it. I am right there that there is a new unified data architecture evolving and I think it is difficult but doable. CQRS and event-sourcing are core elements and the decoupling of the database continues. I also believe Flow Based Programming [2] and reactive programming (observables on top of streams of events) are other key concepts. I've worked on federated database query engines and it turns out that federation has some relationships to this problem. I recently saw this article about Netflix's approach to federated GraphQL (which to me feels like API composition) and found it interesting [3]. I don't know if anything of this helps you but hope it might :) I don't claim to be an expert here but if you're interested in talking more, my email's in my profile. [1] https://news.ycombinator.com/item?id=25285890 https://news.ycombinator.com/item?id=25285890 [2] https://wiki.c2.com/?FlowBasedProgramming https://wiki.c2.com/?FlowBasedProgramming [3] https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2 https://netflixtechblog.com/how-netflix-scales-its-api-with-...

kiwicopple 6y ago

These are great questions. > will you make it as easy as setting up a docker container or helm chart? Yes, likely docker-compose in the short term (for our "local emulator"), and then something more prod-friendly later. Licensing is always a tough decision - we build client libraries for every tool we use, which are MIT licensed. Tools we build ourselves (like the Realtime server), are licensed under Apache 2.0. As you point out, we've started with our hosted platform because we feel this is important (as a business). This par is not yet public (also for security) and we may have to license it with a BSD license when we do open source it. > a subscribable DB engine that handles denormalization One of my favourite topics, and something we've been thinking about for months. It's incredibly hard to solve, especially when you add in Row Level Security and conflict resolution. Our current thinking is some sort of client store, using CRDTs that infer types from the database. We have some ideas for this but it's very early days. I'd love to talk to Liron - I'll reach out.

robertlagrant 6y ago
Just make sure cloud companies can't just host your solution and make easy money from it. The Timescale licence is worth a look.
sixdimensional 6y ago
I like the direction you guys seem to be taking here with Supabase. Regarding the comment about subscription-based DB engine and denormalization, I posted this [1] on the post about Materialize although I don't think anyone read it. I am right there that there is a new unified data architecture evolving and I think it is difficult but doable. CQRS and event-sourcing are core elements and the decoupling of the database continues. I also believe Flow Based Programming [2] and reactive programming (observables on top of streams of events) are other key concepts. I've worked on federated database query engines and it turns out that federation has some relationships to this problem. I recently saw this article about Netflix's approach to federated GraphQL (which to me feels like API composition) and found it interesting [3]. I don't know if anything of this helps you but hope it might :) I don't claim to be an expert here but if you're interested in talking more, my email's in my profile. [1] https://news.ycombinator.com/item?id=25285890 https://news.ycombinator.com/item?id=25285890 [2] https://wiki.c2.com/?FlowBasedProgramming https://wiki.c2.com/?FlowBasedProgramming [3] https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2 https://netflixtechblog.com/how-netflix-scales-its-api-with-...