Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.
Storage is now available in Supabase (YC S20)
11–20 of 82 posts
Re: Storage is now available in Supabase (YC S20)
#12Is there any bandwidth restrictions here using Supabase's storage?
There are no restrictions, however we just released our [Pricing]( https://supabase.io/pricing ) yesterday. TLDR: for the free tier there is a limit of 1GB storage, and 2GB egress/month, pro tier: 100GB storage, and 200 egress/month, and after that it's Pay as you Go.
After we finish integrating Storage with a CDN, the price / GB for egress traffic will be even lower.
Re: Storage is now available in Supabase (YC S20)
#13Quick feedback from your frontpage, the slack demo does not work when trying to sign up https://supabase-slack-clone-supabase.vercel.app/
Re: Storage is now available in Supabase (YC S20)
#14Quick feedback from your frontpage, the slack demo does not work when trying to sign up https://supabase-slack-clone-supabase.vercel.app/
Sorry, we will get that fixed over the next couple of days! p.s thanks for the heads up
Re: Storage is now available in Supabase (YC S20)
#15Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.
wow, that's a glowing recommendation. Thanks for the kind words.
We have a long way to go to catch up with Firebase on most features, but of course we are benefiting from all the hard work that other OSS tools have already delivered. Postgres does most of the heavy-lifting, PostgREST is amazing, and Netlify's GoTrue server is a key piece of our architecture.
Re: Storage is now available in Supabase (YC S20)
#16Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.
> Even if it wasn’t open source it would still be a better alternative.
Well, it's not hard to imagine that, since they don't provide a way to self-host it.
Re: Storage is now available in Supabase (YC S20)
#17Supabase has been better in every way than Firebase. Even if it wasn’t open source it would still be a better alternative. No-sql’s main (only?) appeal is approachability; Supabase makes relational data just as approachable while avoiding the ceiling that every Firebase project seems to hit. Plus its database UI is actually usable.
> Even if it wasn’t open source it would still be a better alternative. Well, it's not hard to imagine that, since they don't provide a way to self-host it.
Hope this helps: https://github.com/supabase/supabase/tree/master/docker
Re: Storage is now available in Supabase (YC S20)
#18Congrats on the launch! I like how you approached adding Storage to the product/platform?, keeping the initial version minimal, yet polished.
I've been following you since the public launch and I'm really impressed by your work and progress. Definitely keeping an eye as you go, Supbase is a tool that could fit really nicely in the projects I'm usually working on (fullstack web, mobile apps).
I wonder what's your perspective on the GraphQL (and Prisma)? I'm asking, since currently I'm working on a project using Redwood.js, with Prisma on the API layer. Prisma helps a lot with my productivity, as my data model is quite complex, with many relationships/nested queries (read heavy). For the same reason, GraphQL increases my speed on the frontend, since there's just 1 query for nested reads and I don't have to play a requests orchestration game (been there before and it's really slowing down development, at least in my experience). The problem with my current project/setup is that auth, storage, realtime and queues/workers parts are... not ideal and fragmented, as I need to use different providers/servers for each (Auth0, Pusher, dealing with S3 integration, separate server for a worker, since redwood is serverless-first). Focusing on auth, I'm not really satisfied with Auth0 and would love to use something else but only if the migration effort would be worth it. And Supbase looks like something that would make the migration worthwhile, as it solves multiple of my pain points. That's the context behind GraphQL/Prisma question -- right now you're REST-first (which is totally fine, don't want any flamewars REST vs GQL) and I wonder how would that fit in my project, which is very Prisma dependent, with 100% GraphQL API. I have some vague ideas but would love to hear your thoughts here and how you think about GraphQL/Prisma + Supbase mid/long term. Thanks.
Re: Storage is now available in Supabase (YC S20)
#19Congrats to the launch! Very impressed with the progress :) Do you have plans to add passwordless auth (either magic link or OTP - preferably OTP)?
Re: Storage is now available in Supabase (YC S20)
#20Why is Supabase as costly as Firebase? Why would I go for a service that's in beta and charges as much as a stable competitor?