[HN Gopher] Supabase Beta: Auth, SQL Editor, Benchmarks
___________________________________________________________________
Supabase Beta: Auth, SQL Editor, Benchmarks
Author : kiwicopple
Score : 117 points
Date : 2020-12-03 14:40 UTC (8 hours ago)
(HTM) web link (supabase.io)
(TXT) w3m dump (supabase.io)
| throwaway32953 wrote:
| Nice! Any timeline on Functions? I saw it's marked as "coming
| soon".
| kiwicopple wrote:
| Hard to know an exact timeline - we will first ship Storage,
| and Functions after that. I think it will be ~Q2 2021.
|
| 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
| nicoburns wrote:
| Would you consider offering some kind of VM or container
| hosting (perhaps similar to Heroku - maybe even built on top
| of Dokku)? Serverless Functions are very popular for some
| reason but (much like the firebase databases) they seem to
| have a lot of downsides (cold starts, hard to test locally),
| and not a lot of upsides (a simple always-on VM is cheap
| anyway).
| kiwicopple wrote:
| Hey HN, Supabase is an open source Firebase alternative. We're
| building the features of Firebase using enterprise-grade open
| source tools. We're particularly focused on scalability. We take
| proven tools like Postgres, and we make them as easy to use as
| Firebase.
|
| 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
| nwienert wrote:
| 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-
| brok...
| kiwicopple wrote:
| 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 wrote:
| Just make sure cloud companies can't just host your
| solution and make easy money from it. The Timescale licence
| is worth a look.
| michelpp wrote:
| Congratulations! As a long time fan of PostgREST I love seeing
| a well thought out product take flight and support their
| community at the same time by openly hiring key open source
| members who have done great work.
| swyx wrote:
| excited about Storage and Functions!
|
| 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!!
| freeqaz wrote:
| Are you using Monaco for the SQL Editor in the browser? If so,
| how did you setup the language server for enabling auto-
| completion/intellisense in the editor?
| axbytg wrote:
| Hello! Emails to work@supabase are getting kicked back. I've been
| working on something similar for hobby use @ apime.dev since the
| pandemic started and would love to chat :).
| kiwicopple wrote:
| Awesome, thanks for the heads-up @axbytg. Fixed.
|
| I 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?
| axbytg wrote:
| No worries at all, would love to! I am available anytime Wed-
| Fri. I can reach back out via email as well if that makes
| scheduling easier.
| snarkypixel wrote:
| The landing page is great too, congrats on the beta launch!
| kiwicopple wrote:
| The landing page was a last minute decision, but we're happy
| that we did it. No doubt there are a few broken links tying our
| old and new sites together.
| tjchear wrote:
| Congrats on the beta launch! Thoughts on supporting multi-tenant
| auth?
| kiwicopple wrote:
| thanks! Supabase is "just" Postgres under the hood, so it could
| be used for multi-tenant already. But I assume you have a
| particular architecture in mind - something we don't offer yet?
|
| We're very open to feedback, our roadmap is often guided by HN
| comments
| steve-chavez wrote:
| Supabase team member here. Multi-tenant is already possible
| with PostgreSQL RLS policies[1]. We provide a nice UI[2] to
| make them simpler to use.
|
| [1]: https://www.postgresql.org/docs/current/ddl-
| rowsecurity.html
|
| [2]: https://supabase.io/blog/2020/08/05/supabase-auth#policies
| ngyekta wrote:
| Congrats on the launch. Waiting for the realtime API to be
| capable of filtering based on row level security and I'll
| definitely try it on some "serious" side projects afterwards.
| Small suggestion regarding the Firebase comparison: Including a
| package size comparison for various Firebase packages (realtime,
| auth etc.) vs Supabase.js might be useful.
| kiwicopple wrote:
| > Including a package size comparison
|
| 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.
|
| [1] https://twitter.com/chiubaca/status/1328654022832758786
| ngyekta wrote:
| I have looked at Firebase core + realtime + auth vs
| Supabase.js and results were very much in Supabase's favor :)
| Understandable though since Firebase is doing a bunch of
| other things under the hood. I would still call it a
| relatively fair comparison.
|
| Also, I think the primary buttons on the website has an
| easily fixable contrast problem. I just created an issue for
| it.
| kiwicopple wrote:
| To be fair to Firebase, they have a lot more functionality
| in their client libraries than ours. But they are
| definitely bloated, and I think they are working on
| reducing their bundle sizes. This is something we are very
| cognisant of - we will keep our bundles modular and easy to
| tree-shake (keeping admin functions separate).
|
| > 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..
| awalias wrote:
| Hey everyone! We put a lot of work over the last few months into
| performance benchmarking. We're very keen for people to run the
| benchmarks themselves and report your results:
| https://github.com/supabase/benchmarks
| avree wrote:
| There's something about this company's design and font/logo
| choice that makes it "feel" exactly like Robinhood.
|
| 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.
| kiwicopple wrote:
| That's interesting - we didn't look at Robinhood during the
| redesign, but the Beta page is inspired by the Stack Overflow
| surveys: https://insights.stackoverflow.com/survey/2020
|
| 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=25071545
___________________________________________________________________
(page generated 2020-12-03 23:00 UTC)