5
points
kiwicopple
Joined 6,207 karma
Supabase (YC S20)
copple [at] supabase [dot] io
- GitHub repo is here if you want to use this for self-hosted Postgres databases:
- 1 point
- > get more Supabase Realtime back into the game if the price was more viable too
feel free to reach out to me on twitter (same username) to discuss this if you want. we are starting to think of realtime in the context of gaming so if you have feedback it would help us shape the pricing
- 2 points
- impressive work jmo - thanks for open sourcing this (and OSI-compliant)
we are working on a challenge which is somewhat like a homomorphic encryption problem - I'm wondering if OpenPCC could help in some way? :
When developing websites/apps, developers generally use logs to debug production issues. However with wearables, logs can be privacy issue: imagine some AR glasses logging visual data (like someone's face). Would OpenPCC help to extract/clean/anonymize this sort of data for developers to help with their debugging?
- this is the last of a 9-part series on database consensus algorithms (like Paxos and Raft):
> Raft improved accessibility but remains a monolithic algorithm that's risky to modify. This has effectively limited our flexibility in adapting consensus systems to modern cloud architectures.
The series begins here: https://multigres.com/blog/generalized-consensus
- 4 points
- let me follow up with the team to find out what happened here
- hey DANmode - supabase ceo here. similar to the sibling thread I want to make sure I know what happened here:
First, I'm sorry you had a bad experience. we have been historically very on-top of our support emails, but this year the tickets have grown ~10x while our team can only grow ~2x. We have had to make short-term trade-offs (automations) which are sub-par so that we can catch up with the growth and primarily focus on the paying customers1. someone created an website using supabase with email logins (and possibly edited the template / opt-out link) 2. someone signed you up to that service - you received an email from that app 3. you sent us an email (to support@supabase.io or similar) to report abuse 4. we emailed a few months later with the generic email you postedI'm be the first to acknowledge that this is something we want to improve. Unfortunately that will take time and iterations - you are experiencing our support (i hope) at it's worst. We sent an email to the backlog of unanswered free-plan emails just to acknowledge and redirect them somewhere we can offer more support
For security/fraud, we have a slightly different process: https://supabase.com/.well-known/security.txt
This process is to ensure that we _don't_ miss emails, like we did with yours.
You post here is helpful for us to figure out the areas that we need to improve. Again, I'm sorry that we didn't give you a good impression the first time - all we can do is iterate based on feedback like yours. If you want to share more my email is in my profile
- thanks for the tag lucasknight - i'll respond inline to OP about their email situation
> your current AWS situation
I think the assessment here is accurate:
https://x.com/theo/status/1979271205279666586
> Looked into this a bit. I don’t think “downtime” is a fair way to report on this. No existing databases are affected. Amazon is literally out of boxes in eu-west-2, so Supabase can’t provision NEW DBs in that one specific region
I want to own the fact that we can be multi-cloud, and that we can work with AWS on their capacity planning (note: this is not a typical request for an increase on a soft limit). We are working through both of these options. That said, the Reddit poster classifying this as days of downtime is not entirely fair, and it makes it harder to for us to over communicate with our community. Throughout this period we had days where there was free of capacity on AWS and we chose to leave the status up until we have finalized our conversations with AWS.
I also want to acknowledge that there is a broader AWS issue today in us-east-1 which affects us (and most other companies today) that is unrelated
- fwiw, we have a team working on OrioleDB at supabase, with the plan to get to GA later this year or early next year. we'll continue to submit patches upstream for the TAM, and of course that will take as long as it takes for the community to accept them. Our focus right now reliability and compatibility, so that the community can gain confidence in the implementation
- An alternative viewpoint which we are pretty open about in our docs:
> our technological choices are quite different; everything we use is open source; and wherever possible, we use and support existing tools rather than developing from scratch.
I understand that people get frustrated when there is any commercial interest associated to open source. But someone needs to fund open source efforts and we’re doing our best here. Some (perhaps non-obvious) examples
* we employ the maintainers of PostgREST, contributing directly to the project - not some private fork
* we employ maintainers of Postgres, contributing patches directly
* we have purchased and open sourced private companies, like OrioleDB, open sourced the code and made the patents freely available to everyone
* we picked up unmaintained tools and maintained them at our own cost, like the Auth server, which we upstreamed until the previous owner/company stopped accepting contributions
* we worked with open source tools/standards like TUS to contribute missing functionality like Postgres support and advisory locks
* we have sponsored adjacent open source initiatives like adding types to Elixir
* we have given equity to framework creators, which I’m certain will be the largest donation that these creators have (and will) ever receive for their open source work
* and yes, we employ the maintainers of Vitess to create a similar offering for the Postgres ecosystem under the same Apache2 license
- Great, thanks for this - we’ll make sure we have something in place
- To add to your point: we didn’t file the patent. we acquired it (at a considerable cost) and we are working to make it freely available
- sam, I think you know me well enough now to know that we're open source through and through. my mistake - I should have been more involved in this process with the team.
It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer.
- sorry about the confusion - I wasn't as involved in this process as I should have been. My fault. This is now fixed:
https://github.com/orioledb/orioledb/pull/558
The code is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer
- fixed - sorry about the confusion.
https://github.com/orioledb/orioledb/pull/558
It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer.
- We are tracking the patches here:
https://www.orioledb.com/docs#patch-set
The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then it should be simpler for anyone to write their own Storage extensions.
I think (correctly) it will take a lot longer to upstream the extension - the PG community should take a “default no” attitude with big changes like this. Over time we will prove its worthiness (hopefully beyond just supabase - it would be good to collaborate with other Postgres providers)
- The current license is PostgreSQL (which is OSI approved)
We could also change to MIT/Apache but we feel PostgreSQL is more appropriate given our intentions to upstream the code
- we will have something to announce in this space within a few months
(if the atlasgo team are reading this feel free to reach out too)
- Thanks for verifying the benchmarks. We’re close to a full RC, aiming for December
Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us
- fwiw, this is not our m.o. - oriole was under development before we took on the maintenance/development.
Our goal now is to ensure that it’s as F/OSS as possible given the pre-existing conditions
- (Supabase ceo)
I’ll revisit this with legal to try make it clearer.
Our intentions here are clear - if people have examples that we can follow we will do what we can to make this irrevocable (even to the extent of donating the patent if/when the community are ready to bear the cost of the maintainance)
- We have made our intentions clear with the core team but also haven’t pushed the agenda much - it’s too early.
The conversations we have had so far are promising, we just need to make sure we approach it the right way. Projects like Oriole have started and sputtered out several times (zheap, for example). The burden first lies on our side to prove that we can see it through to GA, with meaningful usage. They (correctly) shouldn’t need to entertain the maintenance burden until they know the juice is worth the squeeze.
If it’s not accepted into core, we will work with cloud providers to add it as a supported extension
- > But I wonder if the core team, which is famously quite conservative about introducing big changes, sees this as too different to adopt as a replacement
we respect the level of conservatism in Postgres and expect that this could take a while to upstream. we're committed to any timeline and we'll develop it for self-hosters and on the supabase platform first to iron out all the bugs
that said, even if it remains an extension that's fine: as long as the TAM patches land upstream this enables everyone to create storage engines using an extension approach - a very "postgres" way of doing things
you can follow the progress of these patches here:
Our CH wrapper is actively maintained, with push down, parameterized views, and async streaming: https://supabase.github.io/wrappers/catalog/clickhouse/
We see a lot of companies choosing CH with PG - it’s fantastic