Supabase Beta: Auth, SQL Editor, Benchmarks
supabase.io
supabase.io
Supabase had an Alpha launch [1] six months ago. This time we're more stable and feature-full. For the past 2 months we've run benchmarks [2] and security audits and we're confident to take on production workloads.
Our current feature-set includes a realtime engine [3] on top of Postgres, auto-generated APIs using PostgREST [4], and Auth with Row Level Security, OAuth, and magic links [5] . We have a full dashboard, with built-in SQL Editor (full Monaco editor) and a Table View (like Airtable) [6].
Next we are focused Storage & Functions, as well as the local development experience - making sure developers can go quickly from dev to prod.
A few of the team will be here to answer any questions - my cofounder @awalias and @steve-chavez from PostgREST, @inian, and @1_over_n
[1] Alpha launch - https://news.ycombinator.com/item?id=23319901
[2] Benchmarks - https://github.com/supabase/benchmarks
[3] Elixir Realtime engine - https://github.com/supabase/realtime
[4] PostgREST - http://postgrest.org/
[5] Auth: https://supabase.io/docs/guides/auth
[6] Dashboard: https://supabase.io/docs/guides/database
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-brok...
> 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.
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
[2] https://wiki.c2.com/?FlowBasedProgramming
[3] https://netflixtechblog.com/how-netflix-scales-its-api-with-...
for storage, a common pain point is whether or not images (or video) hosted in storage will be CDNified for fast delivery. my dream wish is that there'd be an easy option to specify whether an image should be put on that optimized path, so that when i access it i know whether i'm getting the CDN or the origin version. itd also be nice to do things like specify dimensions or compression quality (basically making it an image optimizing CDN)
for functions - both scheduling and durable functions would be cool :)
both are tricky things to do right for local dev. wishing you all the best!!
> scheduling and durable functions would be cool :)
agreed!
It's on Thor's github right now: https://github.com/thorwebdev/nextjs-subscription-payments
We are currently writing an application where we already have auth set up using AWS Cognito. I haven't been able to find any documentation about it, but is it possible for us to keep using Cognito while still integrating with Supabase and taking advantage of the very nice row level security features, or would we essentially have to roll over to use Supabase for auth as well?
Also, let me just say that it's a huge selling point for us that you're running with Postgres, thank you!
> is it possible for us to keep using Cognito while still integrating with Supabase and taking advantage of the very nice row level security features
Yes, this should be possible, as long as the JWT secret is the same, so that your database (and PostgREST) can determine the user. We can help to figure this out if you want - perhaps in a github discussion? https://github.com/supabase/supabase/discussions
That's a great idea. A developer recently tweeted[1]:
3.gkB gziped vs firebase which is 218.2kB
> Waiting for the realtime API to be capable of filtering based on row level security and I'll definitely try it on some "serious"We have a solution for this underway, and it's great to get this feedback because it helps us prioritise.
Also, I think the primary buttons on the website has an easily fixable contrast problem. I just created an issue for it.
> the primary buttons on the website has an easily fixable contrast problem
Thanks for the fix! We'll merge tomorrow, because the whole team is asleep..
Regardless, congrats on the launch! :)
Surprisingly we don't have too many people asking for this at the moment. A lot of Supabase devs are using Next.js/Vercel or Netlify to write their function code, or using Stored Procedures: https://supabase.io/docs/client/rpc
Just to make sure I understand your question, do you mean falling back from websockets to something like long polling (on https port)?
We're very open to feedback, our roadmap is often guided by HN comments
[1]: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
[2]: https://supabase.io/blog/2020/08/05/supabase-auth#policies
Also, this feels really similar to another project that launched on HN this month, https://news.ycombinator.com/item?id=25059133 (although Supabase focuses more on scalability, while Etebase focuses more on privacy?). Might be some interesting discussion there.
We're quite different from Etebase - I'll copy over the maintainer's comment from this thread[1]:
I think it's very different to supabase.io. They are focusing on being a Firebase alternative, we are focusing on making it easy to build encrypted applications.
[1] https://news.ycombinator.com/item?id=25071545I think I saw an email from you in my inbox but we've been swamped trying to wrap up the Beta. Let's chat next week?
> did you setup the language server
Most of this was baked into the editor. Feel free to open a discussion [1] and I can get our team member to share the technical implementation
[1] Discussions: https://github.com/supabase/supabase/discussions
How does the auth front end work?
> How does the auth front end work?
Once we authenticate the user, the JWT is passed as a header and you can use it in Postgres within Policies (for Row Level Security). We add some helper functions in an auth schema to make this easier