
Supabase (YC S20) – An open source Firebase alternative - vira28
https://supabase.io/
======
DigitalSea
I am ecstatic that someone is finally taking on Firebase. As a Firebase user,
I find it invaluable. Their free plan and limits are very generous. The fact
they offer not only a database, but authentication, hosting and perhaps one of
their biggest features besides authentication: Firebase Functions. I have
API's in deployment that are solely running using Firebase Functions and using
Firestore as the database. The CLI is also another huge Firebase feature.

Following this intently, because Firebase has no true competitor, let alone an
open source one. Nice work so far.

~~~
pier25
I've been using Firebase since 2016 in production and after all these years I
find the service quite lacking.

Both databases are super limited and put all the burden of work to the
client(s) for anything beyond very simple queries.

The functions have some of the worst cold starts I've experienced. Until very
recently the dev experience was terrible but Firebase local dev was released a
couple of days ago so this should be solved.

As for alternatives, AFAIK there is nothing that replicates the whole platform
but there are better options for the individual parts.

\- FaunaDB instead of Firestore.

\- Vercel for edge static hosting + cloud functions.

\- Netlify for everything except the databases

Etc.

~~~
davidb_
FWIW, the cold start issue (which was hitting me with regular 10-30+ second
delays for even the simplest of functions) has recently been "fixed" (at
least, I'm down to <1-2 second cold starts).

The specific issue I was running into: [https://github.com/googleapis/google-
cloud-node/issues/2942](https://github.com/googleapis/google-cloud-
node/issues/2942)

~~~
pier25
Check this benchmark:

[https://serverless-benchmark.com/](https://serverless-benchmark.com/)

It displays data from the last 3 days of tests. Google Cloud has a max peak of
60 seconds for cold starts. It's the second worst after Azure.

~~~
tlarkworthy
Thats an amazing benchmark. Though you have to fiddle with the concurrency
parameter to see that some of the slowness is caused by scaling.

~~~
pier25
OTOH cold starts are calculated with a concurrency of only 10.

The point of using serverless is handling massive traffic spikes efficiently
and cheaply but 10 concurrent connections doesn't seem very massive.

Cloudflare Workers are doing much better than the rest in this respect (see
the max value, the graph is misleading) but these have serious limitations
(eg: max 50ms of CPU time). This makes them a bad fit for most situations.

In my current project which requires lowest possible latency I'm having more
success with Fly.io. Instead of having cloud functions you create docker
images which are distributed on their regions and scale up/down based on
demand on that region.

[https://fly.io/](https://fly.io/)

~~~
tlarkworthy
That's like cloud run which I also prefer. I'll try fly it looks like an even
better fit

------
RNCTX
I see from the links that this is probably borrowing a bit from Postgrest?
I've just discovered Postgrest in the past few days and along with
Postgraphile it seems like all of these projects aimed at "getting back to the
database" are a good idea, I like it. It always bothered me that the first
order of business with any software development framework was to provide a
root/admin database connection. It's like, this thing just explicitly said
we're supposed to ignore all of the security work that went into making that
database software for the past however many decades, and turn it into a dumb
storage medium instead.

The lasting impact of Firebase is it proved to the world that being
opinionated about the database in order to provide good tools is a viable
business model, rather than force ORMs onto people to try and appease every
different database flavor under the sun.

Good luck to you guys, I like the trend.

~~~
pm90
I may be wrong about the history of security work on databases (feel free to
correct me!) , but I think the security model was built mostly for an age
where a single DB would be used by many apps, thus access control at the DB
level seemed natural to the DB admins.

Today, with managed/containerized DBs and Microservices and share nothing
architecture, I’ve seen most apps use their own database instance, in which
case the access control stuff seems to be more of an obstacle than useful.
e.g. just the other day, I ran into issues because the user used for schema
migration did not have access over some tables in my apps database in Postgres
since it has table level access control.

~~~
RNCTX
Not every database application is a public facing web application.

Think about, for instance, a company's internal customer database (including
billing, etc), accessed with internal tools. CSR/Support people need to be
able to see billing status but not credit card numbers, for example. Different
levels of management need to be able to generate reports, but again not get
credit card numbers.

For these use cases the opposite is true. The further you take auth and
permissions away from the database/devops admins, the more times you're going
to need to reinvent auth and permissions boilerplate for every internal tool
under the sun.

Which is a pointless exercise if none of the tools in question are ever going
to be accessible outside of the company's VPN anyway.

Active Directory / LDAP are not abandoned technologies, after all.

~~~
danenania
Access control gets complicated though. Maybe a column should be accessible to
a user, but only under x, y, z conditions that require hundreds of lines of
logic to figure out. Do you really want all that inside the db?

~~~
RNCTX
It certainly does. I've been at a company that had an improper permission
result in a CSR getting elevated access and deleting the whole customer
database, including every single credit card number, by mistake (admittedly
this was back in like 2002). Better still, the devops guy who wrote the backup
scripts had recently quit, and they were broken, the backups weren't being
done. The company-saving backup from the previous day wound up being on an
internal tools developer's laptop. I wasn't a database admin there or
responsible for the permissions, but it was quite a wakeup call for everyone
to double check their stuff when the rumors of what happened got out of the
meetings the next day.

The counter argument is, would it better to have 10, 20, 100 such possible
situations mulling around the building every day, or just one? Maybe if
there's just one, you put enough effort and people into the one to get it
right. That's the pitch for AD / LDAP being used for all auth and permissions,
and I think a compelling one at that.

------
mrtksn
I am a strong believer that Firebase model is the way forward. Huge fan of
Firebase but it is scary to have no proper alternatives. Yes, sure you can
have a similar setup with AWS or bespoke implementation but they are not in
the same spirit.

Very glad to see people working on alternatives.

IMHO though, what makes Firebase special is the glue they use: Account
management and libraries come for free so you can start thinkering on the
interesting parts. Firebase is not just Firestore, it is a set of tools that
work together seamlessly.

When this is achieved, your own product feels mature as if you are working on
implementing a product on top of FB or other established platform and
everything "boring" is handled by someone else.

In my mind, Firebase is a very flexible CMS with sane defaults.

~~~
lukeramsden
Amazon seem to be working on bringing Amplify up to the same standard as
Firebase, and it's certainly getting there, so in the near-future there may be
quite a few alternatives.

~~~
ekseda
I wrote a master thesis where I compared several realtime database products. I
promise you amplify is no where "getting there". It is a crippled version of
firebase and there is no fix in sight. For example you cannot even do sort-
queries with datastore or Amplify is not working with angular because they
have broken typings since 9 months with no fix. And the list goes on..

~~~
taylorwc
Would love to read the thesis if you can share!

~~~
stolsvik
Same here. Is it maybe available from a university website?

------
2mol
This looks great, however at first peek it doesn't mention anything about
auth. Do you have any plans for that? For me this is the topic I most want to
just delegate to the service.

Dashboard, realtime stuff, etc are great too. RESTful APIs I can of course get
with PostgREST [0], which is insanely excellent, so the value I'm looking for
is to have everything managed, from hosting/storage, to security, to all the
other annoying nitty-gritty that I'm likely to get wrong.

[0]: [https://postgrest.org](https://postgrest.org)

~~~
kiwicopple
See my comments on Auth here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443)

> We want to nail the auth and we're looking at leveraging Postgres' native
> Row Level Security. This is a tricky task to "generalize" for all businesses
> but we have some good ideas (we're discussing in our repo if you want to
> follow -
> [https://github.com/supabase/supabase](https://github.com/supabase/supabase))

> RESTful APIs I can of course get with PostgREST

That's what we use! See our supporting libraries:

[https://github.com/supabase/postgrest-
js](https://github.com/supabase/postgrest-js)

[https://github.com/supabase/postgrest-
rs](https://github.com/supabase/postgrest-rs)

[https://github.com/supabase/postgrest-
py](https://github.com/supabase/postgrest-py) (coming soon)

Also, I'm a long time user and a huge fan. My previous company is featured on
their docs (blog post: [https://paul.copplest.one/blog/nimbus-
tech-2019-04.html#api-...](https://paul.copplest.one/blog/nimbus-
tech-2019-04.html#api-layer))

~~~
keyle
Just chiming in... Auth, free hosting and SSL is what drove me to Firebase in
the first place. DB is the last thing.

Just thought you should know, when I read "Firebase alternative", I got
excited about something else.

~~~
kiwicopple
Good feedback - thanks. Stay excited! It's something we will build and we will
make the experience as simple (simpler?) than Firebase

------
sshb
Recently released similar thing for gRPC + Go + PostgreSQL stack:
[https://github.com/sashabaranov/pike/](https://github.com/sashabaranov/pike/)

Features include:

• Generates CRUD operations for given entities

• Generates SQL migration files

• Gives developer full control after project is generated(nothing added on top
of raw SQL/Go)

• Minimal dependencies(basically lib/pq and grpc)

• TLS out of the box

~~~
pm90
What the fuck. This is insanely cool!

------
jaime-ez
Guys, check out
[https://github.com/deepstreamIO](https://github.com/deepstreamIO) \- open
source MIT - I've been a long time user and it works great. It's a typescript
code base, very readable and straight forward, uses protocol buffers for
messaging and uWebSockets.js for the websocket server (ultra fast). You get
realtime records, pub/sub, events, rpc, fine grained permissions, http
endpoints and basically you can hook up to any backend (currently there are
connectors for postgres, rethinkdb, elastic and others).

We need more people to use it, cause the original developer is going on
maintenance mode and we're trying to strengthen the community. It rocks!

------
malisper
I've been thinking about the need for easier to use databases for a long time.
I previously started a company based on selling database software, so I've
seen a lot of problems in the space. I honestly most databases are too hard to
use and there's been no major improvements here in the last few decades.

Take Postgres. You write code in SQL, a programming language unlike any other
mainstream programming language. Instead of writing code with for loops and if
statements, you write it with joins and where clauses. On top of that,
Postgres has a "magical query optimizer" that takes your SQL and figures out
how to execute your query. Unless you have a good understanding of indexes and
how they impact the query optimizer, you'll have a hard time getting Postgres
to be fast. I still regularly say WTF when optimizing Postgres queries even
though I've been doing it for years. That's not to mention there's tons of
database specific terminology like tables, rows, schema, etc, that you have to
learn before you can become an effect user of Postgres.

As much as HN likes to bash it, I think Mongo has done the best job of
creating an easy to use database. With Mongo, you can store JSON and you can
pull JSON out. Of course, I would never use Mongo personally.

I'm hoping that Supabase is able to bring about the next-phase of databases by
not just making it possible to make a database fast, but by making it easy to
do so.

~~~
kiwicopple
This is a great comment. Especially this:

> I'm hoping that Supabase is able to bring about the next-phase of databases
> .. by making it easy to do so

We chatted to a lot of developers at the start of this year. Most of them
thought that Postgres was amazing and wanted to use it, but they still chose
other options (like Firebase) because they were easier. At that point we made
"database UX" our main focus.

------
cultofmetatron
Was going to quip that I built a homegrown version of this in elixir which is
the best stack to implement something like this if you want it to be scalable.

Then I saw that THIS was written in elixir.

That made me take this much more seriously!

~~~
kiwicopple
Elixir really is the perfect tool for this job. Also there are a few features
we are building into the realtime server that will make the system really
shine (and extensible):
[https://github.com/supabase/realtime/issues/33](https://github.com/supabase/realtime/issues/33)

Basically we are refactoring it so you can pipe your database changes anywhere
- webhooks, kafka, serverless, slack etc

~~~
pdimitar
Oh wow, Supabase is in Elixir! You guys hiring?

~~~
kiwicopple
>You guys hiring?

Soon! We are joining the next YC cohort and we will hire after that

Only some parts are elixir. The full stack is here:
[https://supabase.io/humans.txt](https://supabase.io/humans.txt)

~~~
pdimitar
Apologies for shameless plug and off-topic but I am very enthusiastic about
companies using Elixir.

I am a senior dev (18.5y experience in total), currently focusing on Elixir
and Rust (3.5y with Elixir so far, learning Rust fast and currently making an
Elixir<=>Rust bridge for the sqlite database).

I'll be checking out your page every now and then. Do post in the "Who's
hiring?" thread when you are ready to hire! I'll be looking for you there as
well.

~~~
kiwicopple
We'll definitely post in Whos Hiring around September. I'll keep a look-out
for your handle here and around github

~~~
pdimitar
My GitHub handle is `dimitarvp` (and almost everywhere else on the net
really). Thanks for the chat! :)

------
joeyspn
Congrats, the project looks solid. It's obviously targeted to JS devs who are
familiar with firebase or want an easy/similar abstraction for realtime apps.
It's great to have several great frameworks tackling the same problem with
different flavours (Hasura, Phoenix, Supabase, etc), all with postgres as
first class citizen.

I feel like the key is in the choice for the realtime backend
(Phoenix/Elixir). I've built real-time firebase apps (JS) in the past and
today my choice would probably be Phoenix. It also saves many LoC (80-90%?),
and it's a joy to work with. Reduces the JS fatigue and opens up a new
paradigm that makes programming fun again.

~~~
kiwicopple
Realtime is definitely our strongest feature so right now. We started Supabase
to solve a problem at our previous startup, where we built a chat application
using Firebase. Within a few months we discovered our customers were receiving
their chats out-of-order and it took another few more days to figure out it
was due to some Firebase quirks.

We migrated to Postgres and started with Triggers/NOTIFY. But that also has
some limitations (8000 byte payload limit), so we implemented the Elixir
server:
[https://github.com/supabase/realtime](https://github.com/supabase/realtime)

------
gitgud
To be a Firebase alternative, you would expect a full-stack solution; DB,
Auth, Cloud Functions, Analytics...etc. That's the main selling point of
Firebase.

This just seems to be an Open-Source implementation of Firebase's " _Realtime
Database_ ", which is kind of superseded by the new " _Firestore_ ", which is
much more popular.

However it's a smart business move, as many products are locked into the "
_Realtime Database_ ", so this could provide an easy exit door to Open-Source
software.

~~~
kiwicopple
That's true. See my comments here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443)

tldr: > We've been building furiously since January but (not surprisingly) we
haven't yet reached feature parity. But we will :)

~~~
julianeon
I'm a consultant and I love the idea of having Postgres instead of NoSQL on
the backend, coming from Amplify.

For me the MVP, before I could use it for my commercial projects, would be:
DB+auth. At that point, I could switch - and probably would.

Also, kudos to you for being the diametric opposite of a 'useless' startup.
Not only would I use this once I could, I'd talk it up to everyone in my
space.

~~~
kiwicopple
Thanks for your feedback. We hope to have a proper Auth system in place before
our official launch in September.

We like building things that people will use. The number of features that
Firebase offer is vast so it might take us some time, but we will get there
and we’ll make sure we do it in a way that benefits the opensource community

------
BiteCode_dev
A bit of a plug, but if you wish for something that has the Postgres
reliability, the taste of nosql but with strong typing and a json output a la
graphql, give a try to edge db:

[https://edgedb.com](https://edgedb.com)

The team behind it is awesome (one is a python core dev), and it's a FOSS, but
they have been using it internally for some time.

~~~
rhlsthrm
I feel like this is close to what I'm looking for but not quite there in terms
of minimal boilerplate backend. Basically what I want to do is write a GraphQL
schema and have that be the ultimate source of truth. The schema then should
generate the full DB (honestly I don't even care if it's SQL, NoSQL, etc. the
idea is that part is abstracted away). Then the schema can generate fully
typesafe queries for the front end and serverless functions, similar to what
graphql codegen does. I'm almost there with Hasura, but Hasura still requires
definition on the DB side and generates the GraphQL rather than the other way
around.

~~~
electriclove
[https://dgraph.io/blog/post/dgraph-graphql-hits-
ga/](https://dgraph.io/blog/post/dgraph-graphql-hits-ga/)

~~~
rhlsthrm
This looks really interesting thanks for sharing.

------
nmfisher
My app is currently built on top of Firebase but I’m keenly aware of the cost
of lock-in as traffic escalates.

Is this a replacement for the whole suite of Firebase offerings (hosting, auth
and data store) or just a subset?

What’s the migration pathway for someone currently on Firebase?

~~~
kiwicopple
We've been building furiously since January but (not surprisingly) we haven't
yet reached feature parity. But we will :)

> data store

Yes - our data store is _just_ Postgres so you can migrate in/out - no lockin

> hosting, auth

Not yet. We want to nail the auth and we're looking at leveraging Postgres'
native Row Level Security. This is a tricky task to "generalize" for all
businesses but we have some good ideas (we're discussing in our repo if you
want to follow -
[https://github.com/supabase/supabase](https://github.com/supabase/supabase))

> What’s the migration pathway for someone currently on Firebase?

This is also something we're building - a migration tool. Mapping NoSQL to
RDBMS is complex, but something I tackled in my previous company. We'll build
it so that Firebase and Supabase run "in parallel", which we can do since both
have realtime functionality. And then when you're happy, you will be able to
switch off Firebase

~~~
danielscrubs
That's pretty much what I've been wanting for years. Open Source software that
make row level security super convenient via Postgres and OAuth and that can
handle subscription.

Kudos!

------
habosa
Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker
News.

This looks really cool! Honestly I think the Firebase comparison may be
throwing some people off here because this is a SQL-based system, which means
there's a huge base of existing tools/techniques/knowledge to build from.

I like any tool which makes it easier to build an app. It's 2020 and we still
start every app like this:

    
    
      * Pick a database
      * Spin up a server
      * Connect the DB to the server
      * Create a REST API for the server so the client can talk to the DB
      * Somehow make that secure enough
      * Write a bunch of CRUD code on the client
    

What a waste of time! Glad to see people like Supabase taking on this problem
as well.

~~~
pm90
Maybe I am an old fart, but what’s wrong with the steps you mention? What
would your ideal sequence of steps be?

If the answer is “just call an api to handle your data” sure that works for
POCs/Small apps. But I’m a bit hesitant to put all my businesses data inside a
proprietary data store that I don’t control and which isn’t collocated with my
app (Ie every data store request makes a round trip to the google server
hosting the firebase app... maybe not a huge deal if the app itself is in
google cloud?)

Disclaimer: I’ve only used firebase tangentially, haven’t built an app from
scratch with it.

~~~
eatonphil
It's not bad doing it once. Furthermore I'd suggest you do it truly from
scratch once just for the learning experience (no framework [Go makes this
easy] or from TCP socket [synchronous with Python is easy]). However it's
ridiculous going through the same sequence for every single app you build over
a career. Nothing changes, it's all just boilerplate.

I don't want to ever write this sort of boilerplate code again, I want it
generated from a DB schema or something similar [0]. There are better things
to spend time on.

[0]
[https://news.ycombinator.com/item?id=23322300](https://news.ycombinator.com/item?id=23322300)

~~~
skrtskrt
To me there's a sliding scale between productivity, where you use a heavy
framework like Django and Rails to do everything for you, and control, where
you write boilerplate to stitch all your favorite single-purpose libraries
together using your preferred patterns.

They each have their purposes. Django will get you to market fast with all the
features you need, and keep you there for a long time. But it forces (through
its library structure) and encourages (through its common patterns)
ridiculously tight coupling.

I work on a Django Monolith now that runs an org needing to grow beyond it. We
need something not _quite_ offered by a Django library, or we need to move
something with different scaling needs out to another service - it's all
miserably difficult, because they followed all the Django recommended best
practices The framework controls you, you don't control it.

Now we're back to writing boilerplate to enforce a semblance of clean
architecture onto it. It's kind boring sometimes, but once a domain gets
refactored out of the Django way, our ability to deliver features quickly and
safely in that domain goes up 10x.

The "Fat Models" recommendation is one of the most destructive in my opinion:
[https://django-best-
practices.readthedocs.io/en/latest/appli...](https://django-best-
practices.readthedocs.io/en/latest/applications.html), along with Django Rest
Framework "Model Serializers". A JSON serializer that talks directly to the
database is just madness.

~~~
Alex3917
So just don't use fat models. The only sensible way to use Django is to put
all the business logic in service methods, not in models/managers or
serializers/forms.

If all your business logic is in models then of course your app is going to be
completely unmaintainable and it's going to take developers weeks to do things
that should normally take a couple hours.

There is definitely a real problem in the Django community where lots of
people have recommended architecting apps in bad ways, so then you get
developers who want to implement the app the "standard" way that Two Scoops or
whatever recommends. But Django itself is still a great tool, you just need to
be willing call out your teammates if they're unable to think for themselves.

~~~
derivagral
I was just acquired into a team that enthusiastically recommended that book.
Are there any alternative references I could look at or point to as
alternatives? I've used a good bit of Flask but don't have much experience
with Django.

~~~
Alex3917
The book is actually worth reading, there are just some things that I strongly
disagree with. The reason I'm writing my own guide is because there isn't
anything else there that I like.

------
nojvek
1\. I liked that the nodejs example shown here uses async await syntax. I
don’t get why people still put callback hell examples in 2020.

2\. What I really like about firebase is firestore is a scale to zero
database. It doesn’t cost me anything if I have tiny amount of data and low
frequency of users. This lets me spin up lots of small sites at no cost. With
cloud run I have a real api server that also scales to zero. My last GCP bill
was 3 cents. And yes, GCP was dumb enough to actually charge my credit card
for that. Not sure why they don’t have a $1 minimum.

But I like what I’m seeing as supabase’s pitch.

~~~
ssijak
I too have a project on firebase for a small business which costs me 0 but is
vital for this business. I use firestore, cloud functions, auth and cloud
storage for this project. Very nice for small apps.

------
tmvnty
Good luck! It’s great to see another BaaS alternative on the market especially
the recent trend seems to be a lot of Jamstack (backend-less?)

Hopefully open source means better documentation too. Only places I know for
Firebase are their docs and own YouTube channel, which can feel limited once
you pass the “get-started” depth

------
kiwicopple
co-founder here, happy to answer any questions. We're currently in alpha -
app.supabase.io

We also have a lot more to build, so to reward you for your patience we are
completely free right now

~~~
lukeramsden
How does this compare to Postgraphile or Hasura? Or rather, how is it going to
compare once you've had some time to get it out of alpha.

~~~
kiwicopple
Good question - one we get asked often. We don't use GraphQL (but you can do
deep-queries: [https://supabase.io/docs/library/get#query-foreign-
tables](https://supabase.io/docs/library/get#query-foreign-tables))

Under the hood we use PostgREST. At the same time, we may (also) offer GraphQL
using Postgraphile, so people can bring their own client-library.

Differences from Hasura:

\- Auth: we will use Postgres RLS

\- Realtime: we don't use triggers, we use WAL (much more scalable)

\- Only Postgres: Hasura mentioned they will build for other RDBMS. We're all
in on PG and some of the more advanced features (replication, High
Availability)

\- UI/UX. We will build an interface like Airtable, so that even your non-
techie friends can use it

~~~
pkghost
This might be pedantic of me, but conflating RLS and auth isn't a great look.
RLS is a general purpose mechanism for constraining row operations, and auth
has to do with usernames and passwords and session tokens.

~~~
kiwicopple
This is what we are targeting:
[http://postgrest.org/en/v7.0.0/auth.html](http://postgrest.org/en/v7.0.0/auth.html)

We are still doing a heavy assessment of whether this model can be generalised
for everyone. It covers the details of both authentication and authorization -
we are just building a nice/easy way to enable this for everyone (probably
using the same model as Postgraphile:
[https://www.graphile.org/postgraphile/security/](https://www.graphile.org/postgraphile/security/))

~~~
mindhash
i have seen oracle heavily employing RLS for authorization in e-business
suite. and it made things so much easier.

------
eatonphil
This is really interesting. I spent a while a few weeks ago looking around for
a serious, open-source BaaS effort backed by... anyone.

I've been influenced by code generators like xo/xo [0] and sqlboiler [1]
recently (so you can have type-safe APIs and you still manage/own the
resulting code).

My bet is that you can generate an entire API _and_ basic CRUD browser UI from
a db schema. I've been working on a code generator that does this. It can
currently generate an entire Go REST API with CRUD operations from a
PostgreSQL database. Next is to generate a React/TypeScript UI and add auth
support.

The advantage a project like mine has over this is that it defines a standard
API specification and you can build an APIs and UIs against that standard.
Right now the only API is Go, but I'd like to build a Java one too and would
be open to community submissions.

Same thing goes for database dialect. Right now it's PostgreSQL only, but this
kind of code generation can be done on any database once a driver is added.

Won't link to it here because the whole thing is WIP but it's on Github. I see
this kind of project as a long-term base for rapidly building any sort of db-
based applications in the future.

[0] [https://github.com/xo/xo](https://github.com/xo/xo)

[1]
[https://github.com/volatiletech/sqlboiler](https://github.com/volatiletech/sqlboiler)

~~~
kiwicopple
> My bet is that you can generate an entire API _and_ basic CRUD browser UI
> from a db schema

That's what we're building! We already have the auto-APIs, and auto-
documentation. The auto-UI is in the works. It essentially is Airtable, but
backed by Postgres

Also, we will provide "meta" REST APIs for your database. Want to
programmatically add columns or fetch all your database types? No probs.

~~~
eatonphil
As an eng manager, my concern with Supabase is the complexity of the systems
involved. There's PostgREST (Haskell) and then a bunch of Elixir on top? Not
only is that two services (plus the database) but they're in languages that
aren't easy to hire for if I have to do maintenance or development.

I don't think this will be a problem for attracting startups (who will take up
the new hotness) or for large enterprises (where you can package all the
services into a black box that you support). And I get that you're building on
some well-known existing software (PostgREST, primarily) but I'm still
concerned about the operational overhead.

My preference (as an eng manager) would be to operate (and develop hooks for)
a single generated server in Go, Java, or Python rather than manage a real
BaaS.

Still, it's a cool project and good to have open source _and_ backed by YC. I
passed it along to friends whk are looking for this kind of thing. Best of
luck.

------
rickdg
The advantage with firebase web sockets is that when they inevitably get
blocked by firewalls you can always say "Would you mind whitelisting google?
Thanks."

------
leorio
isn't this more like "An open source Firestore alternative" right now. Do you
plan to bring other features as well?

I'm a big fan of firebase and use it whenever I can. The reason it's appealing
it because it's the suite of tools and how well they work together for
bootstrapping (auth, firestore, storage, analytics etc). No single feature by
itself is useful to me.

I would definitely switch if this atleast had (auth + db + file storage +
functions).

~~~
kiwicopple
See my comments here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443)

tldr: > We've been building furiously since January but (not surprisingly) we
haven't yet reached feature parity. But we will :)

------
fragosti
I'm a big fan of Firebase and have seen a lot of projects get up and running
very quickly and scale as well.

However, I think there are an increasing amount of reasons why you want to
have your data stored in a SQL database that you can access. The open source
tooling being built around SQL (usually Postgres) as a standard is becoming
better and better and it's going to be hard for Firebase to compete with all
those offerings. If I run a Postgres database I can instantly have tools like
Hasura [0], Metabase [1] along with others that add a ton of value out of the
box. However, maybe those tools will also integrate with Firebase.

Anyway, my point is that this is best of both worlds, so great to see!

[0] [https://github.com/hasura/graphql-
engine](https://github.com/hasura/graphql-engine) [1]
[https://www.metabase.com/](https://www.metabase.com/)

------
phoenixdblack
The thing that's really invaluable for me is the firebase javascrpt
implementation. Saving the state in a web app and new Objects being
addable/editable offline with firebase automatically synchronising when
network is available with me doing absolutely NOTHING is absolutely insane.
Having just the API isn't really going to cut it.

------
bdcravens
This looks to just be the "real time" DB? How is this different from using
GraphQL subscriptions via Hasura/Postgraphile, or RethinkDB?

Also, it seems like it's missing everything else that Firebase provides.
Authentication, authorization, storage, hosting, etc. To me, Firebase's value
prop is more than just a database.

~~~
kiwicopple
I answered this over here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443)

tldr: > We've been building furiously since January but (not surprisingly) we
haven't yet reached feature parity. But we will :)

~~~
bdcravens
Sounds good. Would it make sense to put some info about your roadmap on your
main marketing pages? There's pros and cons of that, but for positioning sake,
I'd recommend it, and given that it's still an alpha, I think that mitigates
the expectations of feature completeness.

~~~
kiwicopple
Good idea. This post caught us off-guard but I’ll update the site as soon
things settle down

------
aswinmohanme
Finally, waiting for something along the lines of these. Firebase is kind of
the poster child for vendor lock in, and has been around for a long time. It's
time we have some healthy competition.

~~~
arcturus17
Genuinely curious, what are the hot spots for vendor lock-in?

I’m currently building an MVP for a large client and I’m thinking of replacing
Firebase for a custom back-end if the project grows. I think with the current
size it would be easy but I want to avoid passing the point where it becomes
hard to undo.

~~~
kiwicopple
[Supabase cofounder]

Firebase is really only bad if/when you decide to move - usually because of
scaling/performance issues. For example, you can only query one document per-
second. Once you decide to migrate away, it's very painful - but the truth is
all migrations are painful.

This is one of the reasons we chose postgres. If you want to migrate away, you
can just "take your database" with you. PG can scale with the best of them.

Edit: I said "you can only query one document per-second" but this is supposed
to be "you can only query each document once per-second". Sorry!

~~~
almostarockstar
>you can only query one document per-second

That's not true. You can't query any single document more than once per
second, which is very different. You can certainly query many separate
documents per second.

~~~
kiwicopple
Sorry - I intended to write that but I guess I had a freudian slip. You're
100% correct - each document only. Let me put a note

------
ejo4041
The biggest feature I will be looking for in this is a true push to android
mobile devices. It looks like you can use the subscribe function for this, but
I'd need an android example to get up and running quickly. Right now it seems
like firebase is the only game in town for that functionality unless you want
to roll your own with websockets or some sort of MQ. Google also strongly
encourages use of firebase for that in the TOS in the play store I believe.
I'm very excited to see how this progresses.

I also went right to the pricing page to see if you would charge for on-prem
hosting, but looks like it is still TBD. I would like the ability to host
everything on-prem. Security and encryption would be next on my list of wants
after that.

~~~
gdeglin
You're correct that the Firebase Cloud Messaging is essentially required for
Android push. As of Android 8, Google prevents background connections from
being held open by apps, and requires FCM in order to wake up apps (eg: to
receive a notification). This is documented here:
[https://developer.android.com/training/monitoring-device-
sta...](https://developer.android.com/training/monitoring-device-state/doze-
standby)

If the app is already running (eg: in the foreground), then you can (and
probably should) use your own non-FCM connection for sending messages or data.

------
idoby
Couldn't find the info on the website, does the JS shown in the samples run in
the client's browser? If so, I'd be coupling my client code to the
implementation details of my server side DB. Nope, no thanks. Too many scars
to fall for that again.

~~~
kiwicopple
> I'd be coupling my client code to the implementation details of my server
> side DB

[Supabase cofounder] Yes, although you can run this on the serverside too (we
do). It's a rapid way to go "mostly ORMless" \- you just focus on your
database and we can do the repetitive stuff (CRUD)

~~~
renke1
Is there some kind of whitelisting for queries that come from the client as to
avoid the hammering the DB with expensive queries / queries that make no
sense?

~~~
kiwicopple
The auth system we are building is targeting Postgres' Row Level Security
which should cover these sort of problems. (more in my comments here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443))

You'll also be able to add rate-limiting and various other plugins (IP bans,
blacklisting) to your API as well. We still have a lot to build - we didn't
actually post this so it's a bit early but I guess you can't choose your
timing

------
niftylettuce
If you use Mongo, you could easily use just `@ladjs/api` package from the Lad
framework [https://lad.js.org](https://lad.js.org). Deploying is simple, and
you don't have vendor lock-in.

This is a simple example of a `GET /v1/account` API request controller:
[https://github.com/ladjs/lad.sh/blob/4d0a5b5ff822d07e855bbe1...](https://github.com/ladjs/lad.sh/blob/4d0a5b5ff822d07e855bbe164ab03fdbb33d2e89/app/controllers/api/v1/users.js#L30-L34)

If you use SQL, you can submit a PR with `knex` and `bookshelf` option and I
would gladly accept it.

------
kiwicopple
For those signing up - we have hit our cloud limit. we are getting in touch
with them now to increase the limit

~~~
kiwicopple
OK should be sorted. If you have any problems, email us on alpha@supabase.io

------
sradman
Interesting. I haven’t seen a log shipping mobile sync solution in quite some
time. Sybase SQL Remote did log shipping for SQL Anywhere over email or
messaging. This tech predated WiFi, never mind HTTP/JSON.

There is little information about the client side data store other than the
fluent Query Builder API. Is it IndexedDB? How does it handle primary key
generation? Can the client sync a subset of the DB or do you expect to have a
dedicated cloud PostgreSQL instance for every client?

~~~
sradman
Maybe I misunderstood the Firebase comparison. I expected to see a browser-
side database with sync similar to Minimongo in the Meteor real-time
architecture. From my quick scan of the docs and github repos, it looks like
the WAL replication is purely server-side and is used for a type of PubSub
system for change notification. The client can subscribe to these
notifications and issue subsequent queries against the server.

The PostgreSQL specific client-side fluent Query Builder is an alternative to
GraphQL queries but not schema. The PubSub change notifications could be
applied to a GraphQL for PostgreSQL implementation.

Unless I’m missing something, change notification is not the same as pushed
sync in Firebase or Meteor.

~~~
kiwicopple
You are correct here - you nailed the assessment of the serverside CDC. We
will be implementing the client/browser-side database, but only after we nail
auth (see my comments here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443))

------
seanwilson
How do the querying features compare to Firebase? Firebase is notorious for
having an unintuitive lack of server-side query options when you start using
it.

~~~
kiwicopple
We've begun work on our serverside libraries, but we have a way to go. Baby
steps -

Rust: [https://github.com/supabase/postgrest-
rs](https://github.com/supabase/postgrest-rs)

Python: [https://github.com/supabase/postgrest-
py](https://github.com/supabase/postgrest-py)

These libraries underly the core supabase libraries. You can vote for more
libraries here:
[https://github.com/supabase/supabase/issues/5](https://github.com/supabase/supabase/issues/5)

~~~
soedirgo
There's also one for JavaScript: [https://github.com/supabase/postgrest-
js](https://github.com/supabase/postgrest-js)

------
bdcravens
I've only just begun exploring it, but it seems like AWS Amplify is another
strong alternative (just uses underlying AWS services, but with a nice CLI
that ties it all together). Not open source of course, but it's striking to me
that people are only referencing this project as being an alternative to
Firebase - is Amplify not seen as that strong of a product?

------
srikz
This looks great (both Supabase and Nhost)! Years ago I wanted a self-hosted
version of the real-time subscription of Firebase and had come across
DeepStream[1]. It now seems to be in maintenance mode due to lack of
contributors and maintainers. [1]:
[https://deepstream.io/](https://deepstream.io/)

------
brainless
Wow this just made my day! I am building an open source data management
software (aka admin). I am happy to see more software focused at data.

Yay!

------
codecamper
I like this trend of creating a free / low cost version of an entrenched
product & then supplementing with SAAS revenue.

However, the real reason these companies are worth so much is the stock market
& careful stock manipulation carried out by Wall Street firms.

It's a game of using most of your money for AdWords & marketing.

The trick is to grow your revenue at a rate like 40% yoy, starting at a rate
of about 100% and then slowly declining down to a 40% rate.

Of course you pay for this with ad dollars. Wall Street really does not care
how you obtain that growth, just that you do obtain it & every quarter you
"surprise" the analysts with a little more revenue than planned.

In the beginning you can spend lavishly on SG&A so that it's an easy target
for reductions in the future.

And in the beginning you take out massive amounts of money with stock option
grants.

Anyways, my observation is that we could use a Stock Wealth Maximization as a
Service.

------
tomzus
I've recently been playing with firebase and looking for a non-google
alternative. Looking forward to giving this a go.

------
x_stealth
From what can be understood: Writing a backend with Supabase will turn into
managing all these servers.

Backend Server = Supabase (for realtime) + PostgREST (for REST APIs) +
Serverless Functions (for business logic) + Postgres SQL database.

For somebody using Firebase today, How will this solution with Supabase be
simple to manage and scale ?

Help me understand if I am wrong.

~~~
kiwicopple
We plan to make the self-hosting a lot easier/simpler, it's on the roadmap.
This post caught us a bit by surprise - we planned to launch later this year
with better documentation and opensource suppport.

Basically: we will bundle everything into a single deploy (docker, AWS, DO,
etc).

~~~
x_stealth
Got it. But that is a lot to make it work seamlessly.

How do you plan to make any business out of this ?

------
stephen_cagle
I have been working on a Clojurescript wrapper for the Firebase (Firestore)
database. Here is an interactive example of the principle features of that
work. Comments and criticism (and PR's) welcome!

[https://firemore.org/](https://firemore.org/)

------
gbourne1
A plug here, but we built an app around tracking Firebase usage and costs
because there it a worry about getting a big monthly bill. Check it out at
[https://www.firerun.io](https://www.firerun.io)

------
aty268
The problem with these BE services is, unless you refuse to sell out, I can't
reliably build a platform using you.

Google will eventually offer a lot of money to buy you and shut you down.
Prove to me that isn't going to happen.

------
pabs3
Their pricing model is interesting:

[https://supabase.io/docs/pricing/](https://supabase.io/docs/pricing/)

I wonder what the "investors" mailing list is about.

~~~
kiwicopple
Just a few growth stats and updates on key activities. Nothing too important -
just a nice gesture in return for a nice gesture. Happy to add items to the
email if you want them

~~~
vmsp
Out of curiosity, what software are you using to run and manage your mailing
list?

~~~
kiwicopple
We just switched to Intercom (from manual). If there are better suggestions
then I'd also like to hear them - email seems like a space that has a lot of
players and none very good.

------
cwhiz
Seems more similar to Hasura than to Firebase. Firebase adds functions, file
storage, and authentication on top of the database. I didn’t see any of that
mentioned on the site.

~~~
bradyo
Yeah, this title is currently overadvertising the product. Without even
getting into the non-OLTP DB parts of Firebase, Hasura is much further along
towards being a Firebase replacement. It already handles auth and a basic
admin UI for both the schema and data. I respect the vision and welcome more
competition, but this seems to just stitch a "push" system to Postgrest for
now (with no auth to boot).

Hasura also some limited support for generated multi-table transactional APIs,
which Postgrest doesn't. Meanwhile, Firebase supports arbitrary read-modify-
write transactions.

This team has its work cut out for them and I can see a fierce competition
with Hasura and Firebase.

------
imshashank
Awesome product but definitely not a firebase alternative.

------
InvOfSmallC
Besides the pricing, the other painful thing about Firebase are the storage
rules. Given I understand you want to give maximum control to frontend
developers without having a backend, the fact that I need to reimplement them
if I switch serverless is an absolute pain. What are your plan regarding this
aspect. Where are we going to implement the business logic?

~~~
databrecht
Did you check FaunaDB by any chance? I'm wondering whether their ABAC systems
+ UDFs would satisfy your needs.

~~~
InvOfSmallC
I will check it thanks! Although the authentication seems too manual. That
part I prefer firebase.

~~~
databrecht
Thanks, that's valuable feedback :) We indeed are currently providing a lot of
building blocks that can solve a wide range of scenarios but did not focus too
much yet (until now) on providing easy out-of-the-box combinations of those
building blocks that just solve a specific scenario.

~~~
InvOfSmallC
I decided to give it a shot any way. It seems cool.

------
difosfor
How scalable is this? E.g: What is the maximum active (e.g: writing) user
concurrency? What happens when that is exceeded?

~~~
kiwicopple
Under the hood we are _just_ postgres. At the moment every user is on their
own Postgres database with some additional plugins and defaults:
[https://github.com/supabase/postgres](https://github.com/supabase/postgres)

We are already working on High Availability, and we'll give a very simple
point-and-click for replication too (so you can create multiple DB's close to
your customers/audiences)

~~~
treis
How do you handle the creation of the database for a new user?

Any issues with maxing out connections to the DB?

~~~
kiwicopple
Right now when a user creates a "project" we spin up a full server for them.

> Any issues with maxing out connections to the DB?

There are by default 100 max_connections. But if you use our libraries there
is no problem - all requests get funneled through 1 server (which we will
autoscale in the future). You'd be lucky to reach 10 connections. If you
connect to the database yourself then it's really up to you how many
connections you consume

------
risyachka
It hardly compares to Firebase - their main selling points is super quick to
start, easy to use, very cheap, lots of integrations. Unfortunately, all
alternatives to Firebase, even if not counting the large lack of features, are
way more expensive, and lack many integrations, especially mobile.

~~~
kiwicopple
This was posted a bit early (it wasn't posted by us), but see my comments
here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443)

tldr: > We've been building furiously since January but (not surprisingly) we
haven't yet reached feature parity. But we will :)

~~~
risyachka
My point is that sure, there is a valid use case for your service, for people
who are looking for an open-source alternative they can host. But if we are
talking Firebase - most users want exactly the opposite - they don't want to
host their own servers. And when comparing your cloud to Firebase - you won't
be able to compete on price. And probably on features and integrations.
They've been building that for many years now. All I am saying is it not
comparable to Firebase. But lots of people want their own hosted backend they
can extend, or will be glad to pay extra for your cloud and for your unique
features.

------
walkingolof
There is a database management company called Superbase, the names are
confusingly similar. I read a bit perplexed about Superbase being a YC
company. [https://www.superbase.com](https://www.superbase.com)

~~~
Zenst
Superbase IIRC was a GEM based database system that was the era of windows 1.0
comming to birth. Was nice, I mostly did work in Dataease then, and talking
late 80's era.

Dig into the history shows more in depth from my GEM flavour experience.

[https://en.wikipedia.org/wiki/Superbase_(database)](https://en.wikipedia.org/wiki/Superbase_\(database\))

~~~
walkingolof
[https://www.superbase.com/products/superbase-ng-
professional...](https://www.superbase.com/products/superbase-ng-
professional/)

~~~
Zenst
Yes, still going and interestingly enough, so is dataease. Though the old
secret dos debug system in dataease is probably long gone (hold down ctrl and
type debug and you'd get hidden developer options). Software today tends not
to have as many hidden gems like that as yesteryear, bugs perhaps but hidden
features, less so.

------
awalias
here's something small I[supabase co-founder] built with supabase as an
example: Realtime Collaborative Task Lists [https://todo-
zeta.now.sh/](https://todo-zeta.now.sh/)

~~~
awalias
here's a list just for fun/chaos: [https://todo-
zeta.now.sh/?uuid=7e5217bf-7c76-4525-8783-21747...](https://todo-
zeta.now.sh/?uuid=7e5217bf-7c76-4525-8783-21747dc0912b)

------
coderesearch
To keep data in sync is only one aspect of data handling. Take a look at
[https://orbitjs.com/](https://orbitjs.com/) \- not affiliated, just found
that interesting.

------
user0x1d
Is this a good option to host sensitive data? I'll have to opt on a backend to
store medical data in my app. I had discarded Firebase due to some opinions I
found on the web stating it would not be the best option.

~~~
kiwicopple
It's not a good option for medical data. Also, we are far too early and need
to go through a security audit.

At some stage we will make it easy to self-host, and at that point it might be
worth checking out again. If you need any recommended alternatives, feel free
to message me (email in my profile)

------
shireboy
Reading the docs, I'm confused how this is secured. For example, if I have a
table UserOrders (UserId, OrderId, Foo), how do I ensure the backend is only
returning records for the current user?

~~~
awalias
client side auth is not in production yet - but is on the way, more details
here:
[https://news.ycombinator.com/item?id=23320443](https://news.ycombinator.com/item?id=23320443)

------
lukeinator42
This looks great!

One of the main reasons I stick with firebase these days however is how easy
it is to integrate authentication, especially using google accounts with
OAuth.

That would be a cool feature for a future version.

------
MobileVet
What about Parse? YC 2011, acquired by Facebook 2013 and shifted to fully open
source Feb 2016.

[https://parseplatform.org](https://parseplatform.org)

------
aabbcc1241
It looks like a database client driver with realtime (insert only? notice but
why do you call it firebase alternative ?

It sounds like horizon (RethinkDB middleware) but for postgres.

~~~
kiwicopple
Our docs are a bit outdated and overly focused on the realtime server. We also
have auto-generating APIs (with docs that update as you update your database),
a query dashboard, and we are building a table interface like Airtable.

The next big task is auth, which we are working on right now.

~~~
ekseda
Can supabase be used with the offline-first approach like horizon, RxDB etc.
or does it require an ongoing connection to the server?

------
osmanyilmaz
Is that free or not? Cause I didn't see it anything.

~~~
kiwicopple
Right now we're free! But we welcome contributions:
[https://github.com/sponsors/supabase](https://github.com/sponsors/supabase)

See my comment here:
[https://news.ycombinator.com/item?id=23319978](https://news.ycombinator.com/item?id=23319978)

------
rsify
I’m super curious about the real time part - did you pioneer this solution and
why did you pick it over other ones (if any)?

~~~
kiwicopple
This is actually how we started. I was using Firebase and hit some scale
problems. We decided to migrate to Postgres, and I still needed the realtime
functionality.

I started naively: just with triggers/NOTIFY. There were a few tedious things
about this approach (creating a trigger for every table), and one major flaw:
NOTIFY has an 8000 byte payload limit. So we were getting dropped
notifications.

I looked into a few other ways to do it, but nothing fit 100%. So I built it,
but of course with the help of other awesome opensource libraries.

Using the logical decoding is an amazing solution, mostly because you get
message replay if there is an outage. More details in the repo:
[https://github.com/supabase/realtime](https://github.com/supabase/realtime)

------
oreid
If you’re looking for something with a few more features then I recently
discovered [https://appwrite.io](https://appwrite.io)

It includes database (Firestore), storage (Cloud Storage), users (Firebase
Auth) and more, plus you can host it yourself. I haven’t used it myself yet
but keeping a close eye on it.

------
sandGorgon
if you can add graphql as well, that would be good for you as a business.

It gives a migration path for people moving out of firebase and onto things
like graphql. you bridge both worlds.

quick questions - how are you doing conflict resolution ? CRDT or something.

~~~
kiwicopple
> if you can add graphql as well

We are strongly considering it, for the reasons you mention. In the meantime
though, we do already offer "graph like" fetching:
[https://supabase.io/docs/library/get#query-foreign-
tables](https://supabase.io/docs/library/get#query-foreign-tables) (which you
can also use over curl).

> how are you doing conflict resolution

Our realtime library listens to the replication functionality of Postgres.
Basically its an Elixir server that listens to the logical decoding and
converts the byte stream into JSON. You can connect to this via websockets,
but we are also building server-side connectors (like sending to a webhook,
kafka, log etc). Great for CDC use cases

For the client side conflict resolution - we haven't built conflict resolution
into the client libraries yet. It's tough challenge, and we want to make sure
we prioritise some of the urgent tasks (auth)

~~~
sandGorgon
> In the meantime though, we do already offer "graph like" fetching:
> [https://supabase.io/docs/library/get#query-foreign-
> tables](https://supabase.io/docs/library/get#query-foreign-tables) (which
> you can also use over curl).

i appreciate the sentiment, but most people will prefer to go from "npm
install firebase" to "npm install apollo". anything that doesnt fall into one
of those will be a hard sell

~~~
kiwicopple
npm install supabase ? :)

More client libraries coming soon
[https://www.npmjs.com/package/@supabase/supabase-
js](https://www.npmjs.com/package/@supabase/supabase-js)

~~~
sandGorgon
:)

Look I get the sentiment, but you know what I mean. Graphql would be a killer
feature.

~~~
kiwicopple
Honestly we've had a few people asking now - and you've gotta go where your
customers are - so you might see it soon :)

------
zerubeus
This title is click bait for me as Firebase is not only a database and
function...

------
robot
this is super interesting in that I mainly use PostgreSQL and was wondering
how to integrate a real-time database and sync the two for real-time stuff
like comments.

My initial concern is is this stuff stable for production use?

------
doczoidberg
nice project but this is only the database part (firestore/firebase rtdb) of
firebase.

I also haven't read something about authentication and validation. You can't
compare a database without auth with firebase.

------
razin
Congrats on launching! Any plans for a GitLab integration anytime soon?

~~~
kiwicopple
Hey - can you elaborate a bit on the integration and what you'd like it to do?

------
WolfOliver
Nice! ... What are the features you are adding on top of postgREST?

~~~
kiwicopple
We're trying to support postgREST - at the moment that means client libraries:

[https://github.com/supabase/postgrest-
js](https://github.com/supabase/postgrest-js)

[https://github.com/supabase/postgrest-
rs](https://github.com/supabase/postgrest-rs)

[https://github.com/supabase/postgrest-
py](https://github.com/supabase/postgrest-py) (coming soon)

But for additional features, it's a lot of UX - auto-docs, API gateways, auto-
UI (like Airtable). For distinct features, check out our realtime server:
[https://github.com/supabase/realtime](https://github.com/supabase/realtime)

------
tekknolagi
Is this a joke about supa hot fire? Since I'm here for it.

~~~
kiwicopple
Funny story, Supabase was originally a placeholder name - it was a joke so
that Ant (co-founder) and I could entertain each other with Nikki Minaj "Super
Bass" memes while we were brainstorming.

But the name grew on us once we made the initial design. Thankfully Nikki
Minaj isn't well-known amongst techies.

I hope I haven't just ruined our credibility

~~~
petargyurov
That is hilarious, I love it. But hey, maybe it's a sponsorship deal waiting
to happen!

------
sheeshkebab
This has none of the features of firebase that I personally ever used firebase
for (analytics and crashlitics for native apps). Moving along...

------
wizzzzzy
How does this compare to feathers.js?

------
kabes
How does it compare to Meteor?

------
elitan
Wow, I thought I created this thread in my sleep. This is exactly what we do
at Nhost ([https://nhost.io](https://nhost.io)) too.

I usually explains Nhost as Google Firebase, but:

\- SQL (PostgreSQL)

\- GraphQL (Hasura)

\- 100% open source

After being both delighted and frustrated about Firebase I decided that
something must be done. The developer experience on Firebase is awesome but
the tech and the lock-in effect is super bad.

This was the stack I wanted:

\- Hosted service

\- SQL database

\- GraphQL API

\- Subscription (real time)

\- Authentication fully integrated with users in the database

\- Storage also fully integrated with S3 support.

\- 100% open source.

And that's exactly what Nhost provides.

Seeing other services like Superbase, 8base, Firebase (maybe we should change
name to Nbase) is super cool. I think we all can help developers at all stages
to build better apps faster. Very exciting! Good luck all!

~~~
rishav_sharan
That sounds a lot like hasura.io as well.

~~~
elitan
Yea we use Hasura's GraphQL Engine generating the GraphQL API!

------
rplnt
While might work great as a HN title, I don't think that's a wise product
description. First of all, what is Firebase? Is literally no one else than
their users your target? Also, is it OK to use someone else's trademark in
your marketing?

~~~
kiwicopple
Yeah, we don't really want to use competitors names. in saying that - we just
updated the tagline yesterday and it seems to resonate

[https://github.com/supabase/supabase/commit/c905edef57b4b1b0...](https://github.com/supabase/supabase/commit/c905edef57b4b1b09f9af4cf792797b07bad0b46)

We will definitely come up with something better - suggestions welcome
(taglines are hard)

