[HN Gopher] Supabase (YC S20) raises $80M Series B
___________________________________________________________________
Supabase (YC S20) raises $80M Series B
Author : yurisagalov
Score : 182 points
Date : 2022-05-10 16:08 UTC (6 hours ago)
(HTM) web link (techcrunch.com)
(TXT) w3m dump (techcrunch.com)
| ushakov wrote:
| when i tried signing up for their hosted offering they subscribed
| me to a marketing mail list without my consent
|
| i deleted my account immediately after receiving a spam e-mail
|
| this practice is illegal in EU
| adamnemecek wrote:
| Supabase seems cool. Is there something like it if I want to run
| Rust code as edge functions?
| paulgb wrote:
| Supabase edge functions use Deno, which supports WebAssembly,
| which is a decently-stable compile target of Rust. It gets
| tricky when you need to do IO, though.
| adamnemecek wrote:
| How stable is this if I don't need to do IO.
| paulgb wrote:
| The wasm spec itself should be pretty future-proof now, but
| I'm less sure about deno. I'm curious what your use case
| is, happy to take it to email if you like.
| qbasic_forever wrote:
| Deis labs has been experimenting with rust (via WASM) on the
| edge, particularly in the context of a kubernetes cluster.
| Check out https://krustlet.dev/ and
| https://github.com/deislabs/hippo
| MaxLeiter wrote:
| I just started using Supabase on a small side project and am very
| impressed; the ease of setting up realtime was amazing. However,
| the dashboard is so slow. Every action that has a server request
| results in a spinner, even if it could be instant, like creating
| an empty unnamed sql query.
| mritchie712 wrote:
| yeah, it's weird that it take up to 5 seconds to create a new
| query, seems that should be a < 100ms action.
| systemvoltage wrote:
| Unrelated but Cloudflare dashboard used to be like that but
| they did something recently (few weeks ago) and it is blazing
| fast. Everything is instant joy. Well, except the
| Access/ZeroTrust app. Not sure why that's a different app that
| takes 10 seconds to redirect a bazillion times. It has horrible
| UI compared to the main dash.cloudflare.com and generally has
| bad documentation. I guess it exposes internal teams at
| Cloudflare and some broken product management. Hope that gets
| better.
| burggraf wrote:
| Supabase developer here. We hear you. I feel the same thing
| when I use the dashboard. It's on our radar and we're working
| on it.
|
| Thanks for your very kind words about Supabase.
| _query wrote:
| If you're looking for something like superbase but with a more
| end-to-end typesafety approach + optimistic updates, check out
| Thin Backend https://thin.dev/ It takes a bit more of a higher
| level approach to database operations than superbase, which
| allows us to do things like optimistic updates that are hard to
| do in other tools.
| searchableguy wrote:
| How does thin realtime work in the backend and behind the
| scenes?
| _query wrote:
| It's using Postgres pg_notify to subscribe to tables and
| using a WebSocket server to distribute the changes. The table
| watcher is written in Haskell and based on the IHP haskell
| framework. Using Haskell makes it very easy and efficient to
| deal with lot's of active sessions in parallel.
|
| You can find the source code here https://github.com/digitall
| yinduced/ihp/blob/master/IHP/Data... if you're interested :)
| searchableguy wrote:
| That's a similar approach to supabase. Why reinvent the
| wheel? (I'm asking out of curiosity here).
|
| Why websockets? Do you allow bidirectional communication?
| If not, wouldn't it be better to use http push for easier
| scaling?
| wenbo wrote:
| > That's a similar approach to supabase
|
| I'm a Supabase dev and the maintainer of Supabase
| Realtime and just wanted to clarify that Realtime works
| by listening to Postgres' logical replication because we
| realized early on that it scales better and circumvents
| the limitations of pg_notify; for example notify has a
| payload limit of 8000 bytes.
| robertlagrant wrote:
| > That's a similar approach to supabase. Why reinvent the
| wheel?
|
| Supabase is a copy of Firebase. Same question?
| searchableguy wrote:
| Supabase real time is open source while firebase is not.
|
| You cannot provide firebase as part of your services
| because you cannot self host it.
|
| I asked why to understand the reason for another open
| source implementation.
| _query wrote:
| > That's a similar approach to supabase. Why reinvent the
| wheel?
|
| We've initially built the technology already for IHP
| DataSync
| (https://ihp.digitallyinduced.com/Guide/realtime-
| spas.html). So we used what we already had here :)
|
| > Why websockets?
|
| We also use the WebSockets to do write operations. This
| allows for lower latency than doing a HTTP call for any
| API call. Additionally we run all operations in parallel.
| With HTTP push we wouldn't be able to easily run all
| these operations in parallel.
| searchableguy wrote:
| Cool. Thanks for answering.
| dexterdog wrote:
| It charges you $2/GB for bandwidth making you poor very
| quickly.
| halotrope wrote:
| Congratulations, it is well deserved! I have been using SB for
| the past couple months and its great! In my experience what they
| excel at is picking really good components (Postgres, PostgREST,
| Elixir, Kong, Gotrue, Logflare etc) and packaging them with
| little overhead into something that is much greater than the sum
| of its parts.
|
| There are issues of course (slow dashboard, some inconsistencies
| in auth, shaky self-hosting story, a little bloated JS client
| libs) but in general they have a solid offering that is only
| getting better.
|
| I can't stress enough how there is really nothing quite like it
| out there at the moment. I get that HN crowd is always very
| skeptical esp with the somewhat airy opensource/self-hosting
| story that seems a little deprioritized to handle the (probably
| insane) growth. The escape hatches might be a bit rusty a bit at
| the moment but compare that with Firebase and its a little
| inconvenient in SB vs a prison in FB.
|
| I am quite optimistic about Supabase and I wish the team the best
| of success.
| alberth wrote:
| > shaky self-hosting story
|
| What makes it shaky?
|
| That's interesting to hear because it seem like the goodwill
| sentiment regarding Supabase is because you can self-host it.
| halotrope wrote:
| Last time I checked it there was a docker-compose file for
| local deployment but you had to translate that to a working
| production env on your own. Which would include setting up
| the database, setting up Kong on edge-gateway, figuring out
| secrets management, filehosting and updates. One could argue
| that this is normal hoops to jump through when deploying open
| source ofc. It just felt way more laborious than the
| communication suggested. One of the main features the
| "dashboard" was completely unavailable for self-hosted at the
| time. So you would not get quite the same experience compared
| to commercial (again this might be expected for OSS but is a
| little different from what might have been expected initially
| ). I just checked and it seems now there is e.g. a
| (unofficial) k8s deployment plan so it so things might have
| improved. In general it just felt like it was not the highest
| priority to get the self-hosted plan up to parity compared to
| the managed version.
|
| I have no reason to believe that was anything other than the
| product not being quite ready for the aspirations of the
| team. There where some comments on on HN that called the
| Open-Source claims a marketing ploy. I strongly disagree with
| that notion and believe that the SB team is acting in good
| faith and that they will deploy some of that fresh capital to
| further strengthen the OSS story.
|
| Time will tell :)
| pzduniak wrote:
| I've recently done the conversion, used Teleport to get
| access to the dashboard. It works pretty well and I like
| the fact that I can fork GoTrue / point routes at my own
| server-side components, rather than just Supabase.
|
| I agree that a proper Helm chart (or a Kubernetes operator)
| would be ideal. Too bad it would probably also hurt their
| Cloud offerings.
| housel wrote:
| Supabase is featured in the latest episode of the IEEE SE-Radio
| podcast: https://www.se-radio.net/2022/05/episode-511-ant-wilson-
| on-s...
| KaoruAoiShiho wrote:
| How exactly does the scaling work. Anyone remember Meteor? I
| wasted months of my life struggling with it, it scaled horribly.
| giraffe_lady wrote:
| It's postgres behind a naive rest api. You can implement
| caching by hand at the db with materialized views or plv8
| functions or whatever makes sense there. Or at the api gateway
| with cloudflare or something I guess but that's not my area so
| only guesses really.
|
| The realtime stuff can generate a fuckton of writes depending
| on how you have it set up and what your use is, that's probably
| the most likely scaling footgun.
| [deleted]
| wasd wrote:
| The innovation in managed devops is pretty incredible! Had a
| question for the Supabase team regarding authorization and
| PostgREST.
|
| Let's say I have Customer 1 who owns Document 2, 3. Document will
| have a foreign key pointing to Customer. How do I ensure that
| Customer 1 can't access Document 1?
| kache_ wrote:
| one of these will finally stick, and more people will be able to
| build apps
| SOLAR_FIELDS wrote:
| I've been self hosting it for the past couple of months. It is
| a really nice product. Allows one to get fully fledged app with
| backend running extremely quickly, just drop a front end in.
| There's still some annoyances with it though - Work still needs
| to be done to enable backend communication over services using
| SSL - it's currently unencrypted by default. I was able to get
| SSL working with some minor changes to sources and
| configuration but it really should be encrypted by default.
|
| The defaults don't seem super sane either, by default an
| anonymous user can read your entire public database schema via
| OpenAPI (which is turned on by default as well), including any
| RPC's. That alongside the fact that Postgres grants RPC execute
| to public by default means that if someone isn't paying
| attention they can easily expose execute permissions to the
| outside world on functions in their public schema to
| unauthenticated users, and tell them exactly what functions are
| exposed!
|
| The current response from Supabase is to ensure the API gateway
| you use authenticates users first - which isn't really a
| solution IMO, for multiple reasons. I ended up spending some
| time figuring out how to revoke the appropriate database
| permissions from the anonymous role in Postgres, but it
| shouldn't be like that. Anon role should start with nothing and
| the end user should very explicitly be turning on what
| unauthenticated users can access.
| kiwicopple wrote:
| > Anon role should start with nothing and the end user should
| very explicitly be turning on what unauthenticated users can
| access.
|
| We agree. We're working on a pathway towards this. Under our
| original designs we matched all defaults to Postgres'
| defaults, and with any additions the idea was to "stay out of
| the way" during development. It's become increasingly
| important for us to design around security. This will
| definitely mean more difficult development for newbie
| developers, but it's an important step forward.
|
| > I've been self hosting it for the past couple of months. It
| is a really nice product
|
| Thanks for the kind words! The credit also belongs to the
| open source tools we leverage - Postgres, PostgREST, GoTrue,
| Kong
| nicoburns wrote:
| > This will definitely mean more difficult development for
| newbie developers, but it's an important step forward.
|
| Documentation is key here. Default closed policies aren't a
| problem if customising them is in the getting started
| guide.
| qbasic_forever wrote:
| Why just one? I think diversity in this space is good.
| dijonman2 wrote:
| Is this a good thing? We already have a shit ton of useless
| software out there.
| kache_ wrote:
| don't like it? don't use it
| FractalHQ wrote:
| Useless or not, spending less human and environmental
| resources to make something is generally positive, no?
| Supabase enables developers with ideas to easily create
| software with more features thanks to a 1click Postgres
| database + auth + a secure API. I imagine that would
| generally lead to more "usefulness" in an app.
|
| All I need is to do is install the npm package, write some
| psql, and the whole system can be driven securely in the
| frontend. As a dev with more experience in frontend than
| backend, it's quite empowering for me! And I know companies
| who do much more than what I can accomplish with Supabase.
| eddieroger wrote:
| Yes, it is 100% a good thing. Computers should make our lives
| easier, and the best way to do that is to enable people to
| solve their own problems. Not everyone needs to rewrite
| Microsoft Word, but who knows what great idea someone is
| sitting on, just waiting for the tools to make it. Perhaps
| someone has a novel approach to task management, or needs a
| way to track medication but doesn't want to share their data.
| Giving people means to do more with their devices than swipe
| and click is a good thing.
| endisneigh wrote:
| useless to who?
| Msw242 wrote:
| Cheaper bets -> More bets -> more wins -> more winners ->
| more bets
|
| E.g. Shopify absolutely made Ecom 10x easier, which has
| enabled more people to start brands catering to more niches
| while making more entrepreneurs wealthy who then invest in
| other entrepreneurs.
|
| This is only a good thing; the marketplace cannot be too
| crowded.
| sk55 wrote:
| For people who have some experience in this, what's the best
| less-code backends? Hasura? Supabase? Prisma? Thin?
| ttcbj wrote:
| Coming from a rails background, I have really enjoyed
| developing against Firebase.
|
| Cloud Firestore so much easier than deploying a rails app
| somewhere. It comes with a lot of great analytics tools. The
| auth stuff works great. The documentation is very good. It has
| been extremely reliable. Syncing across devices is amazing and
| seamless in my experience.
|
| If it fits your use case (I think mostly CRUD apps with data
| sharing that is somewhat limited in its breadth, e.g. not
| something like twitter with N-N data relationships), it is
| really amazing.
| kabes wrote:
| I'm really happy with hasura.
|
| However, while I've played around with most of the others you
| mention, I haven't build anything serious with them. But hasura
| has a decent authentication story and reactive graphql queries
| are just a really nice dev experience
| praveenweb wrote:
| I can speak about Hasura; I work there :)
|
| Hasura connects to databases and all your other APIs to give a
| unified GraphQL API (and REST API, if you configure it).
|
| This takes care of your CRUD APIs portion of building your app.
| With declarative Access Control Rules, you get powerful
| Authorization. IMO, these two should take care of 70% of your
| application code that you typically end up writing. The
| remaining will be custom business logic that you can write in
| any language or framework of choice and connect it to Hasura.
|
| There's of course more with the cloud offering to give you
| caching, rate limiting and monitoring in production. Hasura
| doesn't host your database, it just needs the db connection
| string to get started.
| jonotime wrote:
| I like Hasura personally and use it on personal projects. Thin
| looks awesome but I cant tell if there is a way to self host.
| _query wrote:
| Thin self-hosting is coming soon :) We already have this
| working on the technical side, we just need to add more
| documentation before we can push it out.
| wingspan wrote:
| Using thin-backend has been one of the most delightful
| experiences I've had making an SPA with a simple backend. The
| developer experience with the generated TypeScript types is
| particularly great, the DB migrations remind me of Prisma, and
| knowing I have a standard Postgres db under the hood is
| comforting. It isn't a large or complex app, but Marc has been
| super responsive to bugs and feature suggestions so it has been
| fun to iterate on. You can find the code at
| https://github.com/ianobermiller/colorcal.
| greatpnwfood1 wrote:
| Appian
|
| they are listed
|
| disclaimer: we use them in our internal infra
| jinjin2 wrote:
| We only have mobile apps, so I can't speak for web apps, but
| for us Realm (https://realm.io/) has been amazing.
|
| The Local API's are a joy to work with. The capabilities of the
| local database makes Firebase look like a toy, and the sync
| service does solid two-way replication between devices.
|
| Definitely one of the best backend-as-a-service we have tried
| (but our experience is mobile only, so yemv).
| technocratius wrote:
| I recently started a project with Appwrite. So far it looks to
| be quite straightforward, the only thing that's annoying is
| their database capabilities. You can only load data via their
| SDK API, so migrating my existing multi million record db is a
| pain.
| endisneigh wrote:
| There's no best really, but in my experience I prefer Hasura. I
| think their security model makes more sense than row level
| security and I prefer GraphQl.
|
| You should try both and see
| michelpp wrote:
| Supabase recently shipped with graphql support that is very
| nice, it maps the query language to the relational schema in
| a sensible way. Without direct experience I understand this
| is similar to how Hasura maps it.
|
| As for your preference for Hasura security vs Postgres'
| native row level security, of course your preference is
| entirely valid and may also be the best fit for your needs,
| but consider that RLS works for _all_ database clients, not
| just Hasura, so if you have a heterogeneous db client
| environment and you want to enforce one central policy, RLS
| can do that but a Hasura specific policy checker can 't.
|
| Disclaimer: I work at Supabase but not directly on the
| GraphQL support.
| chrisweekly wrote:
| Please remedy my ignorance if I might be wrong, but I thought
| Prisma was an ORM, not a true backend.
| rektide wrote:
| I havent been following closely, but Prisma just landed $40m
| series B, & their announcement describes it as an intent to
| grow into an "Application Data" platform.
| https://news.ycombinator.com/item?id=31251167
| davnicwil wrote:
| So I think what they are talking about with platform here
| is just more and better tooling above the data store - like
| the prisma studio product for a uniform interface to data
| for different teams, abstracted above the detail of the
| specific store etc. So not just an ORM on the techincal
| level but that same sort of idea on a business level
| perhaps.
|
| I don't see anything in there about this including plans to
| build their own native data store. Nor do I suspect that
| would be a great idea (really really hard, not their
| competency, nor their point of leverage!)
| chrisweekly wrote:
| cool, ty
| tough wrote:
| Yes, you can use both supabase and prisma with your own
| postgres database
|
| https://supabase.com/docs/guides/integrations/prisma
| ISV_Damocles wrote:
| I've personally found Postgraphile to be fantastic. Nicer to
| use than Hasura and fully OSS:
| https://github.com/graphile/postgraphile/
| _query wrote:
| Thin Backend (https://thin.dev/) is the newest of all of those.
| Compared to Hasura it offers a nicer schema designer. Compared
| to Supabase it offers better end-to-end typesafety and a more
| higher level API that offers optimistic updates. Prisma is more
| like an ORM, so it's designed to be used by a handwritten
| backend.
| algo_trader wrote:
| thin.dev Realtime Bandwidth - $2 per GB
|
| yes please, sign me up !!! /s
| _query wrote:
| Thanks for your feedback :) You have to send quite a few
| json messages to fill up 1GB. We think overall thin
| provides a lot of value and saves a lot of developer time
| (atleast for businesses), so we price it as that.
| searchableguy wrote:
| I think you should use different unit for pricing.
|
| Bandwidth is frequently used in the context of file
| storage which can get expensive really fast even with a
| few users.
|
| This doesn't translate well on the data side where most
| json responses will likely be lower than a few kb.
|
| It's extremely unintuitive which is why I think most Paas
| providers use request and inflate the number (10 million
| requests sounds a lot in comparison).
| ImprobableTruth wrote:
| I echo the sibling: I really recommend you change this.
| Pricing by bandwidth only makes sense if bandwidth is one
| of the main cost factors, because people will,
| consciously or not, compare it to other services that are
| priced by bandwidth.
| dexterdog wrote:
| $2/GB for bandwidth for a pro acct? Is anybody actually
| paying that?
| ehathaway wrote:
| I don't think there is a "best".
|
| I think Firebase has the lowest barrier to entry and if you
| don't exceed the pricing tiers, its a very pleasant experience.
|
| Hasura and Prisma are both awesome, but after having worked in
| GraphQL a lot, I now try to stay at least 10 feet away at all
| times from GraphQL paradigms unless their hidden costs can be
| justified for the project.
|
| I haven't used Thin, but it looks like its React only. If there
| was a Svelte or JS agnostic option Id give it a try.
| _query wrote:
| Thin also supports other JS frameworks. Svelte docs can be
| found here https://thin.dev/docs/svelte We're focussing the
| communication on react mostly to keep things simple. The core
| of thin is independent of react.
| citilife wrote:
| > The service can't, of course, match Firebase on a feature-by-
| feature basis, but it offers many of the core features that
| developers would need to get started, including a database,
| storage and authentication service, as well as the recently
| launched Supabase Edge Functions, a serverless functions-as-a-
| service offering.
|
| Some glowing reviews there... lol
| babl-yc wrote:
| My main critique after trying Google Firestore was: (1) Lack of
| typed schemas with declarative definitions (2) Read/write
| permissions and write validation was extremely complex
|
| From quick glance at the docs, it looks like they make progress
| towards the first but not sure about the latter:
| https://supabase.com/docs/guides/auth/row-level-security
| michelpp wrote:
| Disclaimer: I work at Supabase on database security.
|
| The link you posted is a great guide to sensible security
| practices with Supabase. It's worth noting that the feature
| highlighted, Row Level Security (RLS) is a native Postgres
| feature and not Supabase specific in any way.
|
| https://www.postgresql.org/docs/current/ddl-rowsecurity.html
|
| One immediate benefit of using native security is that it
| applies to all types of database clients and tools uniformly.
| we're not blocked in the future adding more integrations. And
| it works both ways, if you are using RLS in an existing
| postgres deployment you can migrate to Supabase and your
| existing trusted policies will come with you.
|
| It also means that we can avoid creating a whole class of
| security bugs by starting from scratch, and take advantage of
| the millions of collected human-hours of work that already
| exists. Security is hard because it is adversarial and it is
| hard to reproduce or even conceptualize a truly threatening
| environment without experience.
|
| One of our guiding principals is to stand on the shoulders of
| the core developers and not implement our own core security
| model, but to use the native one as a foundation for even more
| powerful security concepts to come. We're actively discussing a
| lot of ways to make this even easier and safer for customers.
| asciimike wrote:
| A long time ago, I was the PM on Firestore security rules,
| which was intended to solve both of those issues.
|
| https://github.com/FirebaseExtended/protobuf-rules-gen was the
| closest we got: declaring types as protobufs (because Google,
| of course) and then generating both security rules to guarantee
| validity as well as client types that would match. I wanted to
| add proto annotations to do additional validity (e.g. add a
| regex to validate the phone number string was correct, do
| length checks on strings, etc.), but we never quite got there
| (not sure proto annotations are a thing externally either).
|
| The short answer is that backend rules engines, either in their
| own DSL or bolted on to e.g. SQL, are pretty tough to get
| right, and have a super steep learning curve. IMO, AWS API
| Gateway with Lambda Authorizers get this most correct: it
| offers a programming model that people are familiar with
| (writing code to access external resources to make the authZ
| decision) with a clear performance tradeoff (ability to cache
| the result for a period of time).
| tlarkworthy wrote:
| Early days but here is an open source Firebase database server
| which you will be able to self modify including JavaScript
| security rules
| https://observablehq.com/@tomlarkworthy/firebase-server-prot...
| dinvlad wrote:
| Amazing product! Started to explore it just a few days ago, as it
| seems very popular among the Indiehackers community. Got a few
| nice-to-haves that I'm sure you're already working on :-)
|
| 1) Auth tokens currently use symmetric signatures, which makes
| them less useful for zero-latency verification in runtimes like
| Cloudflare Workers, and also less interchangeable with other auth
| systems (although it is possible to interchange still by
| implementing a token minting endpoint ourselves, but that's extra
| effort and latency). This would also be really useful for
| integrations with Firebase Auth, which is ironically needed for
| interoperability with other Firebase products not yet in Supabase
| :-) It would be great if you switched to standard RS256 + .well-
| known OIDC endpoints..
|
| 2) Recently added built-in database-driven GraphQL module is
| ingenious, but would benefit greatly from Realtime capability
| (and I know that's hard!)
|
| 3) It's a bit unclear what the multi-zonal or multi-regional (!)
| story is for Postgres. This would be very useful not just for HA,
| but for globally-distributed (reduced latency!) scenarios, like
| the ones addressed by Fly.io Postgres, for example. I know,
| global ACID is hard and expensive, but if we could get closer to
| that (for example, similarly to Fly.io), that would be amazing!
| Right now, it's not clear what the latency story is for users
| accessing Supabase from half-across the world. If you could
| document that at least a bit (incl. which region(s) Supabase is
| deployed in so we could place our backends closer to those), that
| would be awesome!
|
| Thanks so much, this is such an amazing and unique (!) product
| that really fills the void left over by Firebase, particularly
| due to the lack of major progress on Firestore in recent years.
| ehathaway wrote:
| I like the approach Supabase takes in being a light abstraction
| over Postgres and using OSS.
|
| Even in light of the following critiques, I feel like its one of
| the simplest ways for an _experienced_ developer to start a new
| project, and it 's now my go to over spinning up a database,
| Firebase, ORMs, and other database abstractions.
|
| My main critiques are:
|
| - As others have said, default security is way too permissive.
| They should lock everything down by default. At some point, this
| is going to cause major problems for some company that decides to
| build off Supabase.
|
| - Although they have row-level security, RBAC is completely
| missing. It's not hard to implement yourself through stored
| procedures and triggers (they have an example repo to copy from),
| but I don't see a lot of junior devs doing this.
|
| - Stored procedures are more likely to be utilized in the
| Supabase paradigm, but I haven't felt like they have done much to
| address the inherent weakness and common critiques of using
| sprocs instead of application level functions.
|
| - Escape hatches are missing in their fork of GoTrue (why did
| they fork it in the first place - now there are two competing
| versions?). It's still not clear to me how to add data to the JWT
| or get access to the JWT through their SDK.
|
| - Slow dashboard with rendering problems. It doesn't render
| correctly on my Fedora laptop. And the slow speed becomes pretty
| annoying almost right away.
|
| - I have experienced data loss when using their SQL editor. So
| now I copy all the SQL I write to a local file or just do
| everything through DBeaver.
|
| - Lack of backups on the free tier. They should give this away
| for free up to a storage limit. Backups are a critical part of
| development and I don't have full trust in Supabase given that
| I've already experienced data loss through their UI.
|
| - Misleading marketing. They make implicit claims all over the
| place on what they offer but then have disclaimers on their code
| bases about certain features not being production ready.
|
| They clearly have work ahead of them, but I'm optimistic about
| the potential for Supabase and I look forward to the
| improvements!
| michelpp wrote:
| I work at Supabase on database security so I can speak to some
| of these.
|
| > - As others have said, default security is way too
| permissive. They should lock everything down by default. At
| some point, this is going to cause major problems for some
| company that decides to build off Supabase.
|
| We agree and are internally actively discussing this very
| subject.
|
| > - Although they have row-level security, RBAC is completely
| missing. It's not hard to implement yourself through stored
| procedures and triggers (they have an example repo to copy
| from), but I don't see a lot of junior devs doing this.
|
| We don't "have" row level security per se, that is a native
| feature of Postgres we expose, and the customer is free to use
| or not. RBAC is a very broad term, and broadly speaking
| Postgres has roles and privileges that do access control. Did
| you have something more specific in mind?
|
| > - Stored procedures are more likely to be utilized in the
| Supabase paradigm, but I haven't felt like they have done much
| to address the inherent weakness and common critiques of using
| sprocs instead of application level functions.
|
| Weaknesses, critiques _and_ strengths. There are tradeoffs and
| some of this gets down to a matter of opinion. Mine is
| admittedly radical in this case. We recently released Edge
| functions which are great, more tools in the toolbox, including
| stored procedures.
|
| Did you used to work on Zope? You have a familiar handle...
| ehathaway wrote:
| Thanks for the reply!
|
| I've never worked at Zope. Must be my doppelganger.
|
| > We don't "have" row level security per se, that is a native
| feature of Postgres we expose, and the customer is free to
| use or not. RBAC is a very broad term, and broadly speaking
| Postgres has roles and privileges that do access control. Did
| you have something more specific in mind?
|
| I was referring to the ability to assign a user to one or
| more groups and then set, at the group level, access to a row
| or column. When I implemented this, I avoided using PG roles
| b/c I was unsure how this play safely with future changes to
| the hosted DB.
| michelpp wrote:
| > I've never worked at Zope. Must be my doppelganger.
|
| Same last name and first initial as your handle so I took a
| guess. :)
|
| > I was referring to the ability to assign a user to one or
| more groups and then set, at the group level, access to a
| row or column. When I implemented this, I avoided using PG
| roles b/c I was unsure how this play safely with future
| changes to the hosted DB.
|
| This can be done with Postgres' built-in role system. You
| can assign a "group role" to as many roles as you want
| (which in turn, can also be groups, or not) into a
| hierarchy of roles which can be used in any GRANT statement
| or RLS policy. Postgres used to have `CREATE USER ...` and
| `CREATE GROUP ...` but they are now completely subsumed by
| the "new" role system. Both statements still work and map
| to equivalent `CREATE ROLE ...` statements.
| qwertyzxcvmnbv wrote:
| Zope's Hathaway is S ;-)
| kiwicopple wrote:
| Thank you for this write up - it's extremely actionable. Our
| team is already chatting about it internally to find some quick
| wins, and we'll do a deep-dive tomorrow on each of the items
| you've raised.
|
| Some easy ones from me:
|
| > RBAC is completely missing
|
| We are implementing something here, but we need to find the
| right level of abstraction for all/most use-cases. It's still
| unclear to us whether we should make this simply documentation
| ("RBAC with RLS") or actually build the abstraction. We have
| built something internally which we are dogfooding, so watch
| this space.
|
| > Stored procedures are more likely to be utilized in the
| Supabase paradigm
|
| Now that we have released Edge Functions, we have more time to
| work on the blend between both Procedures and Functions. Our
| CLI needs a lot of work, but this will be a major focus for the
| rest of the year.
|
| > They clearly have work ahead of them, but I'm optimistic
| about the potential for Supabase and I look forward to the
| improvements!
|
| Thanks for the kind words!
| ehathaway wrote:
| Thanks for the reply!
|
| Also, is there any plan on the horizon to have the cloud
| offering support Google or Azure? Id love the option to use a
| different provider than AWS.
| bladegash wrote:
| Huge congrats to you guys! Have really enjoyed using Supabase
| with both React and Vue, especially how well things are
| documented (especially so early on in your product's maturity.
|
| I think the sentiment has been shared here by others, but I think
| authentication and authorization are going to be your biggest
| hurdles, yet biggest revenue drivers in the future (e,g.,
| enterprises, startups, etc).
|
| I'd honestly love to see you guys come up with a novel OIDC
| solution, maybe even using Keycloak as the model/goal (which also
| follows the trend of Supabase innovating on existing tech).
|
| Excited to see where you all go from here and the sky is the
| limit!
| kiwicopple wrote:
| supabase ceo here.
|
| I want to give a big shout-out to the HN crowd. You have been
| instrumental in our growth - both from a traction perspective,
| but even more so for product development.
|
| From our initial launch 2 years ago[0], where everyone told us we
| need auth, to our Auth[1], Storage[2], Functions[3], and
| GraphQL[4] launches. You are always giving great (and usually
| tough!) feedback which helps guide the team and product
| direction.
|
| I will be around briefly to answer questions, then back tomorrow
| to cover anything unanswered (it's very late where I am!)
|
| [0] https://news.ycombinator.com/item?id=23319901
|
| [1] Auth: https://news.ycombinator.com/item?id=24072051
|
| [2] Storage: https://news.ycombinator.com/item?id=26635184
|
| [3] Functions: https://news.ycombinator.com/item?id=30868849
|
| [4] GraphQL: https://news.ycombinator.com/item?id=30846006
| hawthornio wrote:
| Seems like there's a typo in Pricing FAQ (emphasis mine):
|
| > Additional usage costs _are billing_ are also billed at the
| end of the month.
| jrmiii wrote:
| I appreciate how you all have open-sourced key elements of the
| platform. I've enjoyed learning from your code. It's also cool
| how you guys don't "code scared" and push the envelope for
| Postgres.
| bgorman wrote:
| Unfortunately this is the wrong team. I have worked on several
| Postgres full stack applications over the past few years, and I
| really wanted Supabase to work, the idea sounded great. The
| JavaScript SDK, the documentation for getting started, and the
| user interface are all horrible/half-baked. Instead of speeding
| up my development, Supabase lead me to waste hours in confusion.
| It is easier to roll your own auth and setup your own database
| than use Supabase unfortunately.
|
| For a product whose whole purpose is to enable developers to move
| faster, the product misses the mark completely. If I were CEO I
| would shift all resources to fixing the UI and SDK.
|
| I would guess out of all the people who have signed up, less than
| 1% have actually made a "working" frontend.
| searchableguy wrote:
| While I don't agree with supabase not being useful, I agree
| that their getStarted documentation could use some work.
|
| I've faced many issues with the twitter auth. For example, you
| need to enable accessing email via an additional option on
| twitter developer dashboard for it to work with supabase. It
| wasn't documented. I've faced bugs which appeared and
| disappeared between upgrading supabase instance (You can have
| different instance version if you created a new application in
| the middle of beta).
|
| The real time doesn't work until you enable the sync on the
| supabase dashboard which was not apparent to me. There are
| bunch of oddities with how policies and realtime work.
|
| The CLI has gone through multiple confusing iteration.
|
| I would still recommend supabase to anyone though. Solid
| despite rough edges.
| wenbo wrote:
| Supabase dev and the maintainer of Supabase Realtime here!
|
| > The real time doesn't work until you enable the sync on the
| supabase dashboard which was not apparent to me.
|
| Thanks for the feedback! I think you're right and we can do a
| better job of exposing this so it's more apparent for
| everyone.
|
| > There are bunch of oddities with how policies and realtime
| work.
|
| Would love to hear more about the oddities! Realtime works
| with Postgres RLS policies so there should be nothing odd
| about it. Set up your policies and Realtime works
| accordingly.
| yesimahuman wrote:
| "Horrible" and "half-baked" don't describe my experience using
| Supabase at all. Yes, they have work to do. Yes, the
| documentation is lacking in certain areas. No, this round
| doesn't indicate they've magically got it all figured out.
| kiwicopple wrote:
| > If I were CEO I would shift all resources to fixing the UI
| and SDK
|
| I'm the CEO :)
|
| Thanks for the feedback. I would love to hear any specifics -
| where you got stuck and which parts of the UI/SDK we can
| improve. My email is in my profile.
|
| We know we have a lot more to do, and we love building based on
| user feedback.
| [deleted]
| onelovetwo wrote:
| Congrats, hopefully this means an iOS sdk soon? :D
| ignoramous wrote:
| > _Unfortunately this is the wrong team._
|
| Ouch. I don't get those vibes from them, but it could also mean
| that building a FOSS platform like supabase is _terribly_ hard?
|
| > _For a product whose whole purpose is to enable developers to
| move faster, the product misses the mark completely._
|
| The good news is, they've now got $80m to hire top talent and
| figure this out over the course of next few years.
| kiwicopple wrote:
| I agree! I think our team is great
|
| But then again, the harsh feedback is usually has the most
| truth. I'll share it with the team - we are always looking to
| improve.
| [deleted]
| alberth wrote:
| Off-topic (and hope the conversation doesn't digress too much):
| when is it ok for someone to monetize an open source project and
| when is it not?
|
| I've read over the years how people get super upset at Amazon for
| taking an open source project, (sometimes) adding some code to it
| and then host and monetize it. The argument being that Amazon is
| monetizing on the backs of countless open source developers.
| Hence why the Common Clause has been added to a number of open
| source projects to prevent this from happening.
|
| Supabase seems to be loved by HN (haven't tried it yet but looks
| interesting).
|
| Isn't Supabase just a wrapper around the open source Postgres
| database (which is BSD licensed)?
| cercatrova wrote:
| One can do whatever the license allows. It is not my fault if I
| monetize someone else's code that is MIT licensed. People
| should read and understand licenses before slapping one on
| their open source project.
| oceanplexian wrote:
| I've been using the MIT license for a decade. It's actually
| free software, not "free but if you fail to follow my
| manifesto I'll sue you". It's more practical since it can be
| used for anything, and it's better for the community since
| people can use it and contribute without risking legal
| liability.
| burggraf wrote:
| Supabase developer here. "Wrapper" is an oversimplification,
| but essentially, we provide additional value to the existing
| OSS offerings (i.e. PostgreSQL, GoTrue, Kong, Postgrest) by
| adding libraries and server configurations that tie everything
| together and make it much easier to develop an application.
| That being said, you're free to self-host Supabase and get all
| this value (and continued value and support) for free. We only
| "monetize" it by offering a hosted version as an option for
| people who would rather not spend time managing servers and
| other infrastructure.
|
| In addition, the value we add to these existing tools is turned
| back to the community and can be used however people see fit.
| alberth wrote:
| Thanks burggraf.
|
| Hope my question didn't come off the wrong way, and really
| appreciate your reply.
|
| Another question, so does Supabase open source 100% of the
| added features/functionality? Or are some
| features/functionality gated behind a paid license?
| burggraf wrote:
| No problem -- it's a very valid question and deserves to be
| clear to everyone.
|
| Supabase open-sources everything and nothing is behind a
| paid license, except for any stuff related to us providing
| the hosted stuff. For instance, our internal software we
| created for billing customers who host with is not
| necessarily open-source.
| fuddle wrote:
| There is a difference between Amazon and Supabase:
|
| - Supabase open source's their backend service product which
| uses Postgres. Anyone could technically fork their project and
| self-host.
|
| - Amazon has a closed source backend service product which uses
| <open-source-database>.
| Lyn_layerci wrote:
| Congrats supabase team!! So proud :)
___________________________________________________________________
(page generated 2022-05-10 23:00 UTC)