Hi, I'm Paul Copplestone, CEO and co-founder of Supabase, the open source Firebase alternative, ask me anything!

2021-07-27
Hi, I'm Paul Copplestone, CEO and co-founder of Supabase, the open source Firebase alternative built on top of Postgres. Supabase already offers realtime subscriptions, authentication and authorization, autogenerated APIs, a dashboard, and object storage. This week, we are doing our second launch week, where we will be launching updated versions of our object storage, authentication, dashboard, and a few more surprise features. Ask me anything!

Links: Website | GitHub | Twitter

AMA Rules:
  • This AMA will be open for questions until midnight UTC on 2021-07-27.
  • All plain text links will automatically be turned into hyperlinks.
  • Please keep your questions specific and to the point.
  • Be chill, we're here to have fun!

32 Comments

This AMA has concluded.
tldrdan   Jul 26
Hi Paul,

Thanks for being here! A few questions:

1) What features do you think Firebase is missing that you plan on adding after you reach feature parity? 2) After launching pricing for your beta a few months ago, what kind of feedback have you received on it? (Pricing announcement: https://supabase.io/blog/2021/03/29/pricing)

Dan
7♥   
paulcopplestone ⭐  Jul 26
> features do you think Firebase is missing



Firebase has a huge number of features so this is a tough one to answer - full credit to them for the amazing product offering. Supabase is just PostgreSQL, so some things we already offer that they don’t “natively” support are: - count functionality: https://supabase.io/new/blog/2021/02/09/case-study-roboflow#leaderboards-that-count - built-in text search: https://supabase.io/docs/guides/database/full-text-search - and (of course) great support for relational joins



For larger features, we haven’t put much thought into this as we generally go where the community guides us. I love the idea of better Maps support (with PostGIS). Would love to hear ideas any other ideas!



> launching pricing



Overwhelmingly positive feedback. We tried to be as generous as possible with indie devs, knowing that we’ll target enterprises later with more expensive features (like Enterprise Auth, SOC II compliance). 



The thing developers love most is unlimited API requests! This was a deliberate decision, because so many people receive shocking bills from Firebase Functions whenever their app/website goes viral. We want our pricing to be *predictable* for indie devs, and we based our tiers on that premise.
6♥   
naltun   Jul 27
> SOC II compliance

Bravo! This is a massive step forward! Good luck!
1♥   
magmatic   Jul 26
This sounds interesting, Paul. I have recently started a project that uses Google Firebase, but I was a bit nervous about vendor lock-in, but this makes me feel better. I have some questions. 1. Since it's open source, what is your business model? Will you offer hosting for a fee? (Supabase as a Service?) 2. Does Firebase currently have any features that you don't? Or is Supabase a full drop-in replacement? 3. Does Supabase have a command-line command to run like "firebase"?
6♥   
paulcopplestone ⭐  Jul 27
> 1. Since it's open source, what is your business model? Will you offer hosting for a fee? (Supabase as a Service?)

We have a hosted platform. You can find the pricing here: https://supabase.io/pricing

> 2. Does Firebase currently have any features that you don't? Or is Supabase a full drop-in replacement?

We're not a drop-in replacement. First difference: we use Postgres rather than a NoSQL database. Our plan is to bring the "developer experience" of Firebase to open source tools (because their DX is world-class). We're just over 1 year in development, so we're missing a lot of features (Functions coming soon, no Analytics yet, no ML). But we're shipping fast since we're using very mature tools like PostgreSQL and PostgREST.

3. Does Supabase have a command-line command to run like "firebase"?

Yeah! - CLI: https://github.com/supabase/cli - Self hosting: https://supabase.io/docs/guides/self-hosting - Local Development: https://supabase.io/docs/guides/local-development
3♥   
touhidrahman   Jul 26
Do you have any plans to use MongoDB anytime soon?
4♥   
paulcopplestone ⭐  Jul 27
We're completely focused on Postgres for now. I think it might be a bit hard to support anything else. For example, how would we implement Row Level Security? how would we do Full Text Search?

But who knows what the future holds ¯\_(ツ)_/¯. You can vote for more databases here: https://github.com/supabase/supabase/discussions/6
2♥   
allaboutthatbase   Jul 26
Hi Paul, when would you advise developers to use supabase vs a standard pubsub like redis or just database postgres?
4♥   
paulcopplestone ⭐  Jul 26
If you plan to use Postgres (or a relational database), then I would advise using Supabase - every project is just a Postgres database with a bunch of extra features out of the box (we even give you raw access to the database). We have auto-generated APIs, Row Level Security, and realtime functionality - all wrapped up into a nice UI.

If pubsub is you a critical requirement for your product, then I would advise going for a more mature product (like Redis). While our Realtime server is getting much more stable, we don't have certain features (like at-least once delivery) that might be critical for a pubsub architecture. If you're using pubsub simply to update a UI whenever there is a change (like a chat application), then Supabase Realtime will fit your needs.
6♥   
awalias   Jul 26
if you weren't building Supabase, what would you be working on?
4♥   
paulcopplestone ⭐  Jul 26
Tough question. It would definitely be in developer tools though.

A few years back I was trying to build "the metaverse" (https://exaquark.com/) in a deep-tech accelerator (which a lot of people are trying to do now). We were focused on the platform rather than the product. There are some huge technical gaps in the current ecosystem, many that have shaped my thoughts around Supabase. For example: offering seamless mapping services, and connecting millions of users in the same "system". I love databases though, and there are so many "unsolved problems", so I'm pretty happy with my career choice :)
5♥   
davehall   Jul 26
What are some projects that are currently being built on top of Supabase?
3♥   
paulcopplestone ⭐  Jul 27
There's too many to mention, so just a few of my favourites:

Epsilon3 (Y Combinator digitizing on Space Operations) https://supabase.io/blog/2021/07/26/epsilon3-self-hosting

Dots (Automation and insights for Slack + Discord communities) https://www.producthunt.com/posts/dots-7

Spot (Map-based video sharing app) https://www.producthunt.com/posts/spot-2d300f54-7a0a-4dbf-aee2-4a75311217cc

Toadli (URL link shortener) https://toadli.co/

And a useful Supabase+Stripe+Vercel SaaS starter template (not an app, but a lot of people using it) https://github.com/vercel/nextjs-subscription-payments
1♥   
naltun   Jul 27
I have been following Supabase since last year, waiting for the 'right' time to give it a try. This AMA makes me feel like there's no better time than now. Congratulations on all of the achievements so far, and I am excited for the future!
2♥   
paulcopplestone ⭐  Jul 28
Thanks @naltun, good luck with building :). If you get stuck, don't hesitate to reach out to us.
1♥   
Taosif7   Jul 27
Hey Paul! I have been using firebase since 2 years and one of its biggest strength (and to why I'm hooked to it) is offline syncing of database. Does Supabase support offline database syncing? If not, do you have plans for it in the future?
2♥   
paulcopplestone ⭐  Jul 27
No, we don't support offline sync yet, but yes - we plan to in the future! I agree with you, it's a killer feature
4♥   
scalfan   Jul 26
How would you compare this project to the open-sourced Parse platform?
2♥   
paulcopplestone ⭐  Jul 27
Disclaimer - I haven't used Parse much so I might be wrong on a few things. I imagine Parse is quite far ahead in terms of features since they have been building for longer.

I think mostly it's a philosophical difference. We support existing open source tools wherever possible and then expose the functionality rather than abstract it. For example, we use Postgres Row Level Security for Authorization rather than a custom middleware implementation. If I compare this to Parse you can use Postgres as a data store, but it's abstracting away a lot of the awesome Postgres features.

The way I see it, we aren't building "a tool", we're building an integrated system of open source tools which work together perfectly.
1♥   
ajcwebdev   Jul 26
Is a hotdog a sandwich?
2♥   
paulcopplestone ⭐  Jul 26
Only if you squeeze it very hard first.
6♥   
noice   Jul 27
Hello! Do you have any plans on allowing auth with simple sessions? (without JWT) This is honestly the only reason that we havent fully committed to supabase yet.
1♥   
paulcopplestone ⭐  Jul 28
I'd love if we could avoid JWT completely and only use session-based Auth.

Unfortunately JWT is pervasive, and it's the first AuthN feature built into most OSS tools. FWIW, we only use JWT for the AuthN, and then once the user is "in" you decode the token to see which user it is (using `auth.id()`). You could even verify the token using the `auth` schema if you wanted to set up your own session-based system.

So I guess the tldr is: we won't natively support session-based auth (anytime soon), but it's completely feasible to set it up since you have full access to the database and auth schema.
1♥   
dqii   Jul 27
Will there be a database migration update this week? :o Really excited for it
1♥   
paulcopplestone ⭐  Jul 27
Unfortunately not this Launch Week - we were planning to but ran into a few hiccups and had to delay. We'll release an updated CLI soon, but we aren't comfortable releasing a migration tool until it's well-tested
2♥   
dqii   Jul 27
No problem! Just wanted to ask, super excited about Supabase :))
3♥   
yureckey   Jul 27
Hasura is somewhat similar to your product, but they choose not to use Postgres Row Level Security for Authorization ("Hasura doesn’t use Postgres RLS so that we can be more flexible by keeping it in the Hasura layer"), can you provide more details why your approach is better?
1♥   
paulcopplestone ⭐  Jul 27
> your approach is better I wouldn't say it's "our approach" but rather the "Postgres approach".

> can be more flexible by keeping it in the Hasura layer I've haven't read the Hasura post you're referring to so it's hard for me to critique their approach. I would say that the onus is on them to prove their approach is more flexible the RLS.

With RLS, you can literally write *any sql* - supabase/postgres doesn't have any opinions on how to structure your database. Multi-tenancy, Access Control Lists, Role Based Access Controls - hell, even data filters (https://supabase.io/docs/guides/auth#time-to-live-for-rows) - all of this is possible with RLS.
1♥   
dqii   Jul 26
Will you guys support GraphQL in the near future?
1♥   
paulcopplestone ⭐  Jul 27
We get this quite often (https://github.com/supabase/supabase/discussions/1057). We PostgREST APIs (which give many of the benefits of GraphQL) but at the same time we're not adverse to adding it in the future. To copy my comment from the GitHub Discussion:

> Not at this stage. I know it seems quick and easy to add a tool, however every time we add a tool to the stack (or release a new feature) we create a considerable amount of work for the team - security, docs, UI, benchmarking, support, libraries, community management around the libraries, employing maintainers, sponsoring etc. We still have a lot of core functionality to add (Workflows, Functions, offline-support on our libraries etc). Perhaps after that we can revisit, and then reach out to the GraphQL communities to see if they are interested in collaborating
3♥   
TDO   Jul 26
What kinds of KPIs do you guys track internally (GitHub stars, # of contributors, etc.)?
1♥   
paulcopplestone ⭐  Jul 27
We have a Hosted platform (i.e. you sign up and get everything without setting it up yourself). Because of this, the most prominent KPI is our "Daily Active Apps", where we measure projects that are receiving 10+ API requests each day. This is a great metric, because it means developers have gone beyond just building - they are getting traction themselves.

We figure if we can keep improving this number, then the rest of the open source KPI's will improve too. We track GitHub stars as our main OSS KPI - it isn't great, but it's understandable
2♥   

TLDR is a daily newsletter with links and TLDRs of the most interesting stories in tech 📱, science 🚀, and coding 💻!

or subscribe with

One email in your inbox every weekday at 6am EST
Privacy Terms  SaaS Churn
Privacy Terms    SaaS Churn
Privacy Terms    SaaS Churn