Supabase (YC S20) – An open source Firebase alternative

https://supabase.io/

by vira28 • 6 years ago

1120 366 6 years ago

supabase.io

kiwicopple58• 6 years ago

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

tmikaeld2• 6 years ago

How much cheaper than Firebase do you expect to be when you launch?

kiwicopple58• 6 years ago

Good (leading) question :)

It's hard to answer because we're so early, so the most honest answer I can give is: i don't know.

Firebase just changed their pricing to "pay as you go". I need to dig into their pricing to give a good comparison but I think we will be much cheaper for the IAAS aspect - we will try offer more value via the dashboard (i.e. we want to build an Airtable-like interface for non-techies to use), and charge on that aspect.

One more thing - we personally find predictable pricing to be an important feature of IAAS and therefore will probably price differently to firebase's usage model.

lukeramsden6• 6 years ago

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.

kiwicopple58• 6 years ago

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)

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

yannikyeo• 6 years ago

How does app handle authn?

kiwicopple58• 6 years ago

see my other comment

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)

imedadel• 6 years ago

About the choice of the database. Why did you decide to go with PSQL instead of a NoSQL database as Firebase does? Doesn't that affect your scalability?

Otherwise, great project!

kiwicopple58• 6 years ago

Actually we chose Postgres specifically because it is scalable. I had to switch from Firebase in my previous company because we hit some scaling limits. Postgres handles the scale no problem - it's crazy the performance improvement we saw (and it's ACID)

The trickiest part was the realtime functionality - https://github.com/supabase/realtime

dexterbt1• 6 years ago

Any link to deployable dockerized versions?

kiwicopple58• 6 years ago

Theres a version here: https://hub.docker.com/r/supabase/supabase-dev

But we will be releasing a much more robust version with docs soon!

warent• 6 years ago

Hey there, I like the product and think your business model is admirable. I would like to make a suggestion that you consider offering some support for your enterprise patrons. $1000+/mo is very steep for an ad even if it was a popular product. imo that should come with some amount of white glove treatment.

kiwicopple58• 6 years ago

That's a good call - let me update!

edit: OK added - https://github.com/sponsors/supabase

nmfisher2• 6 years ago

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?

phreack• 6 years ago

It looks like a way to turn Postgres into a Firebase real-time database alternative, so not Crashlytics, Auth or file storage AFAIK (and I'd suggest making it more obvious on the website if I'm wrong!)

kiwicopple58• 6 years ago

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)

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• 6 years ago

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!

nmfisher2• 6 years ago

Interesting, thanks. I've bookmarked your platform, I'll circle back if/when migration away from Firebase pops back on the agenda.

tekknolagi2• 6 years ago

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

kiwicopple58• 6 years ago

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• 6 years ago

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

BiteCode_dev3• 6 years ago

I'm pretty sure you gain points on HN

tekknolagi2• 6 years ago

Nikki Minaj is great.

aswinmohanme• 6 years ago

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• 6 years ago

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.

cpursley3• 6 years ago

Take a look at Hasura - GraphQL out of the box on top of solid relational database (Postgres)

kiwicopple58• 6 years ago

[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!

closetnerd2• 6 years ago

AWS amiplfiy seems like its trying to do something similar

aidos• 6 years ago

I eventually settled on Hasura but I did evaluate amplify. It looked to me like it was too complicated to break away from their db so I gave up on it (it was possible, but it felt like you had all the complexity of AWS IAM permissions, but just to access data). I didn’t go too deep so I don’t really remember the details but Hasura seemed the better approach (still a happy user of it).

quickthrower22• 6 years ago

This has been around for a while: https://parseplatform.org/

sdan• 6 years ago

thought parse died a while ago with fb?

jinjin2• 6 years ago

Another solid alternative is Realm. We have used it for several projects, and the experience was light years ahead of Firebase.

But since they got acquired by MongoDB things have gone a bit quiet, so who knows?

viig99• 6 years ago

https://github.com/daptin/daptin, DIY self hosted firebase and more!

seanwilson• 6 years ago

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.

kiwicopple58• 6 years ago

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

Rust: https://github.com/supabase/postgrest-rs

Python: 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

soedirgo• 6 years ago

There's also one for JavaScript: https://github.com/supabase/postgrest-js

awalias5• 6 years ago

in addition to @kiwicopple's response, you can also:

- use the js lib - https://supabase.io/docs/library/get

- use your RESTful and Realtime endpoints directly - e.g. <my-app>.supabase.co/rest/v1/users?select=first_name,age

- or even just connect to the db directly using your favorite SQL tools/ORM

sandGorgon3• 6 years ago

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.

kiwicopple58• 6 years ago

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 (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)

sandGorgon3• 6 years ago

In the meantime though, we do already offer "graph like" fetching: 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

awalias5• 6 years ago

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

awalias5• 6 years ago

here's a list just for fun/chaos: https://todo-zeta.now.sh/?uuid=7e5217bf-7c76-4525-8783-21747...

doczoidberg• 6 years ago

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.

osmanyilmaz• 6 years ago

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

kiwicopple58• 6 years ago

Right now we're free! But we welcome contributions: https://github.com/sponsors/supabase

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

InvOfSmallC3• 6 years ago

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?

databrecht3• 6 years ago

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

InvOfSmallC3• 6 years ago

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

sradman2• 6 years ago

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?

sradman2• 6 years ago

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.

kiwicopple58• 6 years ago

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)

elitan4• 6 years ago

Wow, I thought I created this thread in my sleep. This is exactly what we do at Nhost (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!

abhishektwr• 6 years ago

Looks great. Gone give a try.

andai• 6 years ago

Nbase sounds cool to my ears :) Good luck to you!

rishav_sharan• 6 years ago

That sounds a lot like hasura.io as well.

411111111111111• 6 years ago

It's almost like I it's an hasura app! Oh,wait..........

elitan4• 6 years ago

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

asar• 6 years ago

I've played around with Hasura and HBP for a side-project and have to say I'm really happy with the developer experience so far. Great work and thanks for making it open source as well!

elitan4• 6 years ago

Happy that you enjoy it. My pleasure.

niftylettuce• 6 years ago

If you use Mongo, you could easily use just `@ladjs/api` package from the Lad framework 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...

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

mrtksn• 6 years ago

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.

lukeramsden6• 6 years ago

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.

cwhiz3• 6 years ago

I find the overall Amplify offering to be a mess. The hosting and authentication works pretty well but the rest of it just feels like they put duct tape in front of a bunch of existing AWS services.

I’ve found Hasura+Cognito+S3 as the closest equivalent to Firebase. It’s not as neatly wrapped up into a single product but it’s pretty close.

ekseda2• 6 years ago

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..

idoby• 6 years ago

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.

kiwicopple58• 6 years ago

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• 6 years ago

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?

rplnt• 6 years ago

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?

kiwicopple58• 6 years ago

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...

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

pabs3• 6 years ago

Their pricing model is interesting:

https://supabase.io/docs/pricing/

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

kiwicopple58• 6 years ago

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• 6 years ago

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

srikz• 6 years ago

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/

2mol3• 6 years ago

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

godzillabrennus• 6 years ago

Any thoughts on Auth0?

https://auth0.com/

2mol3• 6 years ago

Love it, used it, mildly dislike the pricing.

But generally I'm of the opinion that auth tightly integrated into the platform has a lot of advantages. My dream is to avoid (almost) all glue between my components, I think Firebase became successful in big part because of that.

tluyben22• 6 years ago

I saw this passing by a lot of times, but either I misunderstand the pricing or it is indeed 'enterprise' pricing. Because even small sites I launched have easily 10s of 1000s of users and some have had millions => I cannot see this pricing work at all on any of those without me closing the doors (having margins that are just too small or just making losses) vs making a really good living.

cwhiz3• 6 years ago

I have found Cognito to be a similar enough, if not more quirky, offering, but at a fraction of the cost. Auth0 is just too expensive.

kiwicopple58• 6 years ago

See my comments on Auth here: 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)
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-rs

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-...)

2mol3• 6 years ago

Oh, that's super cool!

I'm even more excited for your project in that case. I hope I can make the time to build a prototype, right now I'm doing the same for retool, and I feel very spoiled for good choices all of a sudden when it comes to backend abstractions.

nicoburns2• 6 years ago

You might want to look into how Hasura does auth. IMO it's really well thought through. However, it doesn't handle the actual authentication, just the access permissions afterwards. If you could layer firebase-style auth "strategies" (email/password, Facebook, Open ID, etc) on top of that kind of system, while keeping everything accessible directly in the main database, that'd be pretty awsome.

pdimitar5• 6 years ago

Just FYI, making a good auth solution in Supabase will instantly make me a customer.

keyle• 6 years ago

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.

fulafel• 6 years ago

Are you also using PostgREST in the backend to provide the APIs, or are your REST APIs and hence client libs PostgREST compatible?

rsify• 6 years ago

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)?

kiwicopple58• 6 years ago

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

wizzzzzy• 6 years ago

How does this compare to feathers.js?

leorio• 6 years ago

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).

kiwicopple58• 6 years ago

See my comments here: 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 :)

tomzus• 6 years ago

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

cultofmetatron2• 6 years ago

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!

kiwicopple58• 6 years ago

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

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

pdimitar5• 6 years ago

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

cultofmetatron2• 6 years ago

I was looking into debezium to do this but an elixir solution would be fantastic. I'm trying to solve this in my own startup. Are you guys on the elixir slack? would love to sync up.

sshb• 6 years ago

Recently released similar thing for gRPC + Go + PostgreSQL stack: 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

pm905• 6 years ago

What the fuck. This is insanely cool!

eclat• 6 years ago

Almost like Rails.

tmvnty• 6 years ago

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

BiteCode_dev3• 6 years ago

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

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.

rhlsthrm3• 6 years ago

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.

BiteCode_dev3• 6 years ago

That's pretty much why people created ORM for, though.

E.G: Django ORM will let you define the schema, and be the single source of truth for you DB and your REST API.

databrecht3• 6 years ago

I'm wondering how FaunaDB's GraphqL would suit you? It's basically: "drop in schema, get API". You can't do everything that you'll ever need yet but you can go quite far and the implementation of each query is efficient since every query is one query and thus one transaction, is backed by indexes that are automatically generated and finally we are quite suitable for GraphQL-like queries. (because those are a bit like tree-walking queries for which the 'Index-free Adjacency' concept in graph databases is very suitable and FaunaDB's References are quite similar. Although we're not a Graph database we don't have problems with huge graph-like joins because of that. besides that, the compatibility of our native FQL language made it ridiculously easy to generate an FQL query GraphQL queries)

If there is something missing in our GraphQL feature set, feedback is very welcome :).

electriclove• 6 years ago

https://dgraph.io/blog/post/dgraph-graphql-hits-ga/

Hoenoe• 6 years ago

Checkout: https://prisma.io

kiwicopple58• 6 years ago

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

kiwicopple58• 6 years ago

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

DigitalSea• 6 years ago

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.

punnerud• 6 years ago

Firebase smell the Google Maps model with its “free” for a long time plan, before turning up the price when most of the market is used to the product and are to deeply locked to the API.

mav3rick9• 6 years ago

Why shouldn't they charge for a great product ? When Google charges it's a problem when they don't charge it's a problem.

Red_Leaves_Flyy• 6 years ago

Just this year, Google/firebase has dropped their flat monthly fee plan which increased the spark plans limits. Just this week cloud functions have been removed from the free spark plan, which will break a lot of peoples apps.

These decisions are alienating to me. I've been working on migrating my heroku mern stack app to firebase but now I'm having serious second thoughts. I was initially attracted by the free and flat fee plans. I won't ever sign up for a service that demands absolute liability without any way to put hard limits on expense. Without a way to put an absolute maximum limit on expenses, whether $10k or 0.01, I'll never upgrade my account on firebase.

I've spent this week reviewing some alternatives and standing up everything myself on a vps is more attractive then losing sleep over the possibility of my crappy code bankrupting me on firebase.

blunte• 6 years ago

I've read too many stories of people and companies being temporarily (and possibly permanently) incorrectly flagged/banned from Google (by some algorithm).

If your business depends on Google, you are taking serious risk. Even if you have a contact within Google who can champion your case, a loss of your Google services could end your business.

tr33house2• 6 years ago

I wouldn't worry about this. Any examples?

pier255• 6 years ago

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_• 6 years ago

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

ElFitz• 6 years ago

Have you checked Amplify? Haven't had the chance to really do anything with it yet, but I've heard quite a lot of good from a few people.

jbirer• 6 years ago

I am not sure if I can get behind this. Company invests work and money into a product, makes it free for the community and smaller businesses to use only to have people turn around and copy it and break the "you use my product for free and give me some publicity" contract. Something is ticking me off morally on this.

aabbcc1241• 6 years ago

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.

kiwicopple58• 6 years ago

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.

ekseda2• 6 years ago

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

kabes• 6 years ago

How does it compare to Meteor?

brainless• 6 years ago

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!

RNCTX4• 6 years ago

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.

kiwicopple58• 6 years ago

You're right about PostgREST. See my comments here: https://news.ycombinator.com/item?id=23321132

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

I couldn't agree more

block_dagger• 6 years ago

With containerization and network orch layer, the db often isn’t the best place to enforce access perms.

pm905• 6 years ago

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.

RNCTX4• 6 years ago

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.

bavell3• 6 years ago

I'm curious to hear what others think about this as well. I run some WordPress sites in containers and I give each one it's own DB instance. I just create the root account with a strong password, give it to WordPress and call it a day. Makes ops much simpler although it's probably not the best use of resources (e.g. memory).

Any big downsides to doing things this way? I'm no DBA so I appreciate any insights.

sheeshkebab• 6 years ago

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

_lbaq2• 6 years ago

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

twic• 6 years ago

There's also a Nicki Minaj song called Super Bass, although i admit that is less likely to get confused with either of them: https://www.youtube.com/watch?v=4JipHEz53sU

kiwicopple58• 6 years ago

I posted this below, but since you mention Nikki -

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

Zenst2• 6 years ago

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)

_lbaq2• 6 years ago

https://www.superbase.com/products/superbase-ng-professional...

razin• 6 years ago

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

kiwicopple58• 6 years ago

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

cwhiz3• 6 years ago

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• 6 years ago

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.

habosa• 6 years ago

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.

pm905• 6 years ago

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.

time0ut3• 6 years ago

I've used Firebase for a couple MVPs. It is very fast to develop on. It makes it easy to get a web or mobile app up in a few hours once you know what you're doing. It is definitely possible to be that fast using other technologies, but the learning curve is higher.

When you're just experimenting, trying to find market fit and get something to stick, Firebase is a decent solution. I haven't tried anything sizeable on it though. Eventually, I'm sure we would've migrated if we were successful enough.

eatonphil9• 6 years ago

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

beisner• 6 years ago

Excellent for deploying small auxiliary apps that are not necessarily your company’s core competency, or a side project.

DarkWiiPlayer• 6 years ago

What's more, in the days of IaaS you can just as easily spin up a new server in some web interface, copy-paste a setup script you wrote once and after getting a coffee you come back to a working database server that does 90% of what you need. How much automation we use is independent of how much of this automation we decide to outsource.

EDIT: But hey, maybe that's just me not understanding the 2020 mentality of "Take my data and make it work" well enough

grizzles• 6 years ago

My ideal would be sqlite in the back, sqlite in the browser, with a sync table that uses database triggers for managing a log of the normal tables.

I've written a few more thoughts here: https://github.com/ericbets/erics-designs/blob/master/funcdb...

mercer3• 6 years ago

I can't help but mention that I rather like the alternative approach of keeping steps 1-3, and using Phoenix LiveView (or C#'s Blazor?) for the rest. Not saying it's better or worse, but I quite like it.

rakoo2• 6 years ago

If you don't pick a db, where do you store data ?

kiwicopple58• 6 years ago

Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system

You're correct - we're building on top of Postgres so it's not a perfect comparison. And we're a bit early to even make it a fair claim.

I'm glad the crowd here has been so receptive. We were planning of launching in September, but it must have been picked up somewhere on the internet (thanks @habosa)

dandare• 6 years ago

Hi, do you plan to be a full BaaS? With Authentication, email confirmations, push notification etc?

gbourne• 6 years ago

This looks awesome. Realtime and easy access to Postgres. However, I'm not sure where the Firebase comparison comes in. You can't really even say it is a Realtime DB or Firestore comp since those are no-sql.

You might want to take off the Firebase comp until ready otherwise it distracts from the cool offering.

narrationbox• 6 years ago

If you are adding Auth the Firebase way, remember to add an UI for JWT claims. Right now Firebase does not explicitly expose the list of claims UI through the dashboard so everytime you change permissions you have to programmatically iterate through everything if you want a holistic overview.

fwoty2• 6 years ago

Just a counter datapoint, the Firebase comparison is what got me to click on the link and check it out. I'm a huge Firestore fan... here's what would get me to try something new:

- Better user permissions, ability to actually see my users and user permissions in a UI

- Better ability to choose conflict resolution logic

- Tied to that, ability to get "patches" from the server... right now if a change happens in my Firestore document, the server sends the entire document to the client. I'd love to be able to get a patch with just the changed data (and of course send patches to the server too, which it looks like you would support).

- Join queries to save me from needing to do multiple client -> server trips. If it's SQL I'm guessing you would support this.

Very interesting project! I'll be following your progress.

pier255• 6 years ago

There are solutions like Hasura or Fauna which give you a GraphQL server automatically.

How come Firebase still doesn't have some sort of agnostic querying layer?

eatonphil9• 6 years ago

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

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

jimktrains22• 6 years ago

I built something a while ago call bam[0] that basically did that. You specces your application in an xml file and it built out the admin ui, orm code, and db schema. I took a bet on a soon to be dead framework and ultimately didn't have time to continue the project, but it worked pretty well.

eatonphil9• 6 years ago

That makes sense. I'm hedging against dead technology by keeping the database and code generation parts separate from the templates. This way you can have templates for any languages so long as they speak a shared (HTTP) API specification.

kiwicopple58• 6 years ago

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.

eatonphil9• 6 years ago

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.

eatonphil9• 6 years ago

Here's [0] the docs site for the code generator I'm working on. It generates a Go REST API with basic CRUD operations (plus filtering, pagination and sorting).

Next up is authentication and a React UI.

[0] https://eatonphil.github.io/dbcore/

user0x1d• 6 years ago

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.

kiwicopple58• 6 years ago

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)

phoenixdblack• 6 years ago

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.

rickdg• 6 years ago

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."

gitgud• 6 years ago

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.

kiwicopple58• 6 years ago

That's true. See my comments here: 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 :)

rdslw• 6 years ago

Feature parity with Amazon Firebase?

Let me assess this, with the tip of my napkin:

1. linkedin 'firebase' + amazon (current employer) -> 695 people.

2. 10% of above = 70 FTE

3. They started (googled): They founded Firebase as a separate company in September 2011 and it launched to the public in April 2012.

1+2+3 = It's impossible you will have feature parity in next 10 years.

BUT it's possible you can achieve pareto parity, leaving off the table most complicated 20%. Good luck :)

julianeon• 6 years ago

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.

WolfOliver• 6 years ago

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

kiwicopple58• 6 years ago

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

https://github.com/supabase/postgrest-js

https://github.com/supabase/postgrest-rs

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

difosfor• 6 years ago

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

kiwicopple58• 6 years ago

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

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• 6 years ago

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

Any issues with maxing out connections to the DB?

risyachka2• 6 years ago

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.

kiwicopple58• 6 years ago

This was posted a bit early (it wasn't posted by us), but see my comments here: 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 :)

risyachka2• 6 years ago

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.

imshashank• 6 years ago

Awesome product but definitely not a firebase alternative.

nojvek• 6 years ago

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.

ssijak2• 6 years ago

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.

malisper• 6 years ago

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.

kiwicopple58• 6 years ago

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.

aty268• 6 years ago

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.

x_stealth2• 6 years ago

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.

kiwicopple58• 6 years ago

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_stealth2• 6 years ago

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• 6 years ago

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/

fintechie• 6 years ago

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.

kiwicopple58• 6 years ago

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

shireboy• 6 years ago

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?

awalias5• 6 years ago

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

ejo40412• 6 years ago

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.

ejo40412• 6 years ago

It's clear I jumped to a conclusion here and thought this would give us firebase cloud messaging, my bad.

awalias5• 6 years ago

Thanks for the feedback! We've had a few people asking for on-prem + support, it's looking like it's going to be bumped up the feature queue.

Also thanks for sharing the android use case - we definitely want people to use this directly from the client. We're working hard to get the auth model right for this.

gdeglin• 6 years ago

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...

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.

bdcravens3• 6 years ago

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?

bdcravens3• 6 years ago

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.

kiwicopple58• 6 years ago

I answered this over here: 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 :)

bdcravens3• 6 years ago

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.

nick-garfield2• 6 years ago

AFAIK Firebase doesn't actually offer any real authorization do they? It was some time ago I last built a project with them, but I remember having to create a custom "roles" attribute in the Realtime DB for users.

lukeinator42• 6 years ago

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.

jaime-ez• 6 years ago

Guys, check out 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!

oreid• 6 years ago

If you’re looking for something with a few more features then I recently discovered 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.

robot• 6 years ago

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?

MobileVet• 6 years ago

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

https://parseplatform.org

gbourne1• 6 years ago

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

coderesearch• 6 years ago

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

fragosti• 6 years ago

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 [1] https://www.metabase.com/

zerubeus• 6 years ago

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

codecamper• 6 years ago

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.

Supabase (YC S20) – An open source Firebase alternative

Related Stories