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.
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
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.
Probably similar in an overall sense to Postgraphile et al[0], in case you haven't seen that - although I am also interested in the specifics relating to Supabase.
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/)
Two of your points are future feature promises. One of them is how Hasura plans to support other DB's besides Postgres, which they've already been exclusively working on & supporting for multiple years at this point.
Another mentions that you have plans to build a UI for non-technical people. This isn't different either, Hasura already has this too.
The triggers part is also downright wrong. Check the technical document on scaling to 1,000,000 live queries.
Discussions about the scalability and tradeoffs of WAL, Triggers, and the decided implementation (interval-based polling) are given:
"We experimented with several methods of capturing events from the underlying Postgres database to decide when to refetch queries."
"Listen/Notify: Requires instrumenting all tables with triggers, events consumed by consumer (the web-server) might be dropped in case of the consumer restarting or a network disruption."
"WAL: Reliable stream, but LR slots are expensive which makes horizontal scaling hard, and are often not available on managed database vendors. Heavy write loads can pollute the WAL and will need throttling at the application layer."
"After these experiments, we’ve currently fallen back to interval based polling to refetch queries. So instead of refetching when there is an appropriate event, we refetch the query based on a time interval. There were two major reasons for doing this:..."
You're 100% correct about their triggers and thanks for the link. I actually hadn't read it but I did today after waking up and it's quite fascinating.
Hasura is a great product and it deserves all the love it gets here. Tanmai and exchanged a few messages in February, so we're aware of what eachother are working on. I don't really feel this space is a player-takes-all market (see also nhost, graphile, subzero, amplify - all great products).
The parent comment "how is it going to compare" so I listed a couple of promises. It's up to us now to deliver on those promises - we're only a small team and our startup is 5 months old, but we move fast. I don't plan to disappoint. Sorry this reply took a few hours, I wanted to make sure I read your link (and slept) before commenting.
> 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)
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?
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)
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.
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!)
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
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.
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.
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.
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.
In Hasura your still need a 3rd party service such as Firebase or 0Auth for Authentication. Also, it depends on Serverless functions for doing any business logic.
> In Hasura your still need a 3rd party service such as Firebase or 0Auth for Authentication
That's false. You can write your own service or use some open source authentication system, like you would in a normal website. Or use JWT tokens. It doesn't have to be a 3rd-party service.
nhost.io basically does this. it packages Hasura with its own auth backend, as well as an S3 compatible storage backend. They're adding lambda functions soon.
Effectively a firebase alternative using open source tech
For business logic you can trigger (Events) webhooks to any service or stack of your choice or use GraphQL schema stitching. And now there's a new Actins feature as well.
This is a misconception. Hasura doesn’t depend on serverless functions for doing business logic.
If you are comfortable writing GraphQL, you can add your own custom GraphQL server to Hasura for business logic.
If you are comfortable with REST APIs (or something that already exists), you can use Hasura Actions to define GraphQL types and call your REST endpoint to perform business logic.
Now where this server is hosted is totally upto the user. It can be serverless functions or can be a monolith server (in language of choice) hosted anywhere.
Perhaps what they meant is it requires application code (server or severless) for business logic mutations, instead of surfacing database functions as RPC.
This was the particular reason I moved away from Hasura. Business logic mutations in SQL are too powerful to give up and replace with JavaScript in opinion.
A key insight I've arrived at over past few months is GraphQL is most useful for multiple teams to have "one" API endpoint and they can then work on front end features without blocking each other, as well as write different clients (and therefore many different possible "queries") without having to constantly re-write the back-end API. In other words, ultimate flexibility on the front end when you don't know what queries you need and you need to divide work across teams/developers.
This comes at the cost of complexity of implementing a performant GraphQL server. Perhaps another instance of a thing that gets really popular because it's good for large corporations rather than being ideal for solo devs or small projects. Like NoSQL and other scalability optimizations vs sql etc. Hasura seems the best I've come across so far at making this easy/quick.
But in many situations, at least for my use-case and likely many others, simply writing well thought out SQL queries are both simple, easily iterated upon, require fewer layers, infrastructure, code etc. In the Hasura scenerio, custom SQL queries inevitably are needed anyways, Hasura mostly gets you the "crud" operations quickly.
If you construct your "screens" or "pages" of a Next.js web-app, for example, as collection of RPC's defined in SQL either requested through "/api" routes integrated with the framework, or even better (when possible) directly accessing your database calls [using raw sql of course] within component "getServerSideProps" and "getStaticProps" calls[0], there isn't really anything simpler in my view. No ORM, no Graphql.
By RPC, I simply mean a stored sql function, or view. Executing this is as simple as:
// some api endpoint, which then queries database:
await db('select pay_balance($1)', [leaseId]);
return res.status(200).send("ok");
The stored function is written in SQL, not javascript http requests, and has full access to all the data in the database to implement transformations on this data.
Reading "The Art of Postgresql"[1] currently and a constant refrain is to push as much business logic into the database as possible. When you do this, you avoid so much complexity vs having this spread around in application code or cloud functions or microservices, etc. ACID, transactions, etc. all come with it.
The tagline: "Turn thousands of lines of code into simple queries" couldn't be more impactful in my thinking of late, and it's been extremely beneficial for making me more productive with simpler, less error prone code.
> you can add your own custom GraphQL server to Hasura for business logic
> If you are comfortable with REST APIs (or something that already exists)
This is an order of magnitude worse than simply having to "depend on serverless functions". You're saying for any real-world business logic (read: non-crud writes to the database, every app has these), you need to re-implement another graphql server? or simply have something that "already exists" to solve your problem? Isn't that what Hasura is for?
> Now where this server is hosted is totally upto the user.
I think the dream of Hasura-like products is to not have a bunch of servers everwhere that need to be managed and coordinated. This is the beauty and power of Postresql. Containing our business logic in it is ideal. At the very least, containing our business logic in 1 Hasura instance would be 2nd best. Calling out to some other rest api or custom implemented GraphQL server defeats the purpose of a self-contained GraphQL layer. If some of the data lives elsewhere, sure. But what if the data just lives in our database?
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!
So are you saying there is no way to get a database dump of firebase, so you have to query both your old and new databases (and deal with all the resulting consistency issues) for a transition period unless your service wants downtime?
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.
"you can only query one document per-second".. uhm, that doesnt sound right, it would make firestore useless for all intents and purposes. The only limitation I know that sounds close to that is 1 _write_ per second for the _same_ document.
We used https://parseplatform.org/ hosted at back4app.com, so we had all the turnkey benefits up-front and the ability migrate as we required more control; there is no need to lock-in at the start. But if you are already 'stuck', I'd focus on using it only in the MVP context for throw-away experimentation.
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).
When FB/Twitter/whoever dropped it, they open sourced the platform completely — they just weren’t offering managed hosting anymore, and they weren’t maintaining it. This looks like a maintenance effort by the community that has formalized itself
I keep meaning to give it a go self-hosted, but I have this horrible feeling it needs MongoDB, but I should check that again.
I tried it when Buddy hosted it for free and its quite nice. I prefer it to Firebase because it felt like the API was simpler and more discoverable. I think the fact that no company is "pushing it along" means it stays simple.
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.
How does this relate to something like https://gun.eco/ ? Wouldn't Gun be able to scratch the same itch as Firebase and on top of that you'd have the advantage (or disadvantage, depending on your point of view and use case) of it being decentralised?
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)
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
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?
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.
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?
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.
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)
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!
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!
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.
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.
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.
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.
Yes I completely agree actually, I've been using Amplify to prototype UI quite well but my plan is to switch to using Postgraphile (or maybe Hasura, I haven't decided yet) + Cognito to replace the backend - primarily so I can use a relational database that isn't Aurora Serverless. I do feel like they've made good progress on the project in recent months, but it really needs another good year of work on it before I'd consider it cohesive enough to stick with.
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..
Neither of those issues surprise me, from what I've seen of the project.
I'm not familiar with the project historically, as I've only been using it for about 2 months, but it seems to me like there's been an increase in activity since the start of the year - like the package modularization, new UI components, and new docs (which are still pretty bad to be honest). I totally agree it's sub-par to Firebase, and if you stray anywhere off the beaten path you're completely on your own (i.e. not using React, seemingly (!!)), but I do think it has the potential to become a viable alternative.
My primary issue with the platform is the choice of a NoSQL database, which, in my view, just doesn't match the majority of application requirements - if you want to do any sort of text search, you have to spin up a whole sodding Elasticsearch domain, which are expensive as hell for a new product and take literally 20-30 minutes every time they're updated with an `amplify push` command. I also waited over a week for one to be deleted not too long ago. That's why my plan is to replace the API with a Lambda function running Postgraphile with some JWK logic to use Cognito for authN, while keeping the idM and file storage stuff.
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.
> 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)
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?
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)
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
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?
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
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.
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/
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.
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.
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.
We have a microservice for this which we use. It's internal and was extracted from systems/practices that grew over years. Basically it works like Auth0 many of the bells and whistles, but it's just a service in our network. And, probably not a surprise, TCO (cost of running/maintaining it) is a rounding error (few $100/month) for millions of users.
> 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)
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.
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.
Likewise.
Firestore client API is nice and convenient, but it is so limiting on queries. One has to know the limitations and plan ahead on how to model the data around them, or risk the ability to do even some fundamental queries [0].
[0] https://stackoverflow.com/questions/47251919/firestore-how-t...
Each database gets it's own PostgREST instance, a realtime server, an API proxy, and a Postgres admin api (which we are building) to manage their schema programatically.
We have client libraries for PostgREST, which then gets installed as a dependency in our main client library.
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
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).
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.
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
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.
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.
373 comments
[ 3.1 ms ] story [ 269 ms ] threadWe also have a lot more to build, so to reward you for your patience we are completely free right now
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.
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
[0] https://www.graphile.org/postgraphile/security/
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/)
Two of your points are future feature promises. One of them is how Hasura plans to support other DB's besides Postgres, which they've already been exclusively working on & supporting for multiple years at this point.
Another mentions that you have plans to build a UI for non-technical people. This isn't different either, Hasura already has this too.
The triggers part is also downright wrong. Check the technical document on scaling to 1,000,000 live queries.
Discussions about the scalability and tradeoffs of WAL, Triggers, and the decided implementation (interval-based polling) are given:
https://github.com/hasura/graphql-engine/blob/master/archite...
"We experimented with several methods of capturing events from the underlying Postgres database to decide when to refetch queries."
"Listen/Notify: Requires instrumenting all tables with triggers, events consumed by consumer (the web-server) might be dropped in case of the consumer restarting or a network disruption."
"WAL: Reliable stream, but LR slots are expensive which makes horizontal scaling hard, and are often not available on managed database vendors. Heavy write loads can pollute the WAL and will need throttling at the application layer."
"After these experiments, we’ve currently fallen back to interval based polling to refetch queries. So instead of refetching when there is an appropriate event, we refetch the query based on a time interval. There were two major reasons for doing this:..."
Hasura is a great product and it deserves all the love it gets here. Tanmai and exchanged a few messages in February, so we're aware of what eachother are working on. I don't really feel this space is a player-takes-all market (see also nhost, graphile, subzero, amplify - all great products).
The parent comment "how is it going to compare" so I listed a couple of promises. It's up to us now to deliver on those promises - we're only a small team and our startup is 5 months old, but we move fast. I don't plan to disappoint. Sorry this reply took a few hours, I wanted to make sure I read your link (and slept) before commenting.
> 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)
Otherwise, great project!
The trickiest part was the realtime functionality - https://github.com/supabase/realtime
But we will be releasing a much more robust version with docs soon!
edit: OK added - https://github.com/sponsors/supabase
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?
> 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
Kudos!
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
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.
That's false. You can write your own service or use some open source authentication system, like you would in a normal website. Or use JWT tokens. It doesn't have to be a 3rd-party service.
Effectively a firebase alternative using open source tech
https://www.nhost.io
For business logic you can trigger (Events) webhooks to any service or stack of your choice or use GraphQL schema stitching. And now there's a new Actins feature as well.
If you are comfortable writing GraphQL, you can add your own custom GraphQL server to Hasura for business logic.
If you are comfortable with REST APIs (or something that already exists), you can use Hasura Actions to define GraphQL types and call your REST endpoint to perform business logic.
Now where this server is hosted is totally upto the user. It can be serverless functions or can be a monolith server (in language of choice) hosted anywhere.
Hasura just needs the endpoint :)
This was the particular reason I moved away from Hasura. Business logic mutations in SQL are too powerful to give up and replace with JavaScript in opinion.
How are you surfacing RPCs from the database? That sounds interesting.
This comes at the cost of complexity of implementing a performant GraphQL server. Perhaps another instance of a thing that gets really popular because it's good for large corporations rather than being ideal for solo devs or small projects. Like NoSQL and other scalability optimizations vs sql etc. Hasura seems the best I've come across so far at making this easy/quick.
But in many situations, at least for my use-case and likely many others, simply writing well thought out SQL queries are both simple, easily iterated upon, require fewer layers, infrastructure, code etc. In the Hasura scenerio, custom SQL queries inevitably are needed anyways, Hasura mostly gets you the "crud" operations quickly.
If you construct your "screens" or "pages" of a Next.js web-app, for example, as collection of RPC's defined in SQL either requested through "/api" routes integrated with the framework, or even better (when possible) directly accessing your database calls [using raw sql of course] within component "getServerSideProps" and "getStaticProps" calls[0], there isn't really anything simpler in my view. No ORM, no Graphql.
By RPC, I simply mean a stored sql function, or view. Executing this is as simple as:
The stored function is written in SQL, not javascript http requests, and has full access to all the data in the database to implement transformations on this data.Reading "The Art of Postgresql"[1] currently and a constant refrain is to push as much business logic into the database as possible. When you do this, you avoid so much complexity vs having this spread around in application code or cloud functions or microservices, etc. ACID, transactions, etc. all come with it.
[0] https://twitter.com/adamwathan/status/1246144545361997829 this uses a query builder, I wouldn't even do that. Just raw sql everywhere.
[1] https://theartofpostgresql.com/
The tagline: "Turn thousands of lines of code into simple queries" couldn't be more impactful in my thinking of late, and it's been extremely beneficial for making me more productive with simpler, less error prone code.
We already support user defined PG functions to be exposed as graphql queries so this is a natural extension.
> If you are comfortable with REST APIs (or something that already exists)
This is an order of magnitude worse than simply having to "depend on serverless functions". You're saying for any real-world business logic (read: non-crud writes to the database, every app has these), you need to re-implement another graphql server? or simply have something that "already exists" to solve your problem? Isn't that what Hasura is for?
> Now where this server is hosted is totally upto the user.
I think the dream of Hasura-like products is to not have a bunch of servers everwhere that need to be managed and coordinated. This is the beauty and power of Postresql. Containing our business logic in it is ideal. At the very least, containing our business logic in 1 Hasura instance would be 2nd best. Calling out to some other rest api or custom implemented GraphQL server defeats the purpose of a self-contained GraphQL layer. If some of the data lives elsewhere, sure. But what if the data just lives in our database?
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!
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.
You can test it for free with back4app.com (happy customer, no affiliation)
I keep meaning to give it a go self-hosted, but I have this horrible feeling it needs MongoDB, but I should check that again.
I tried it when Buddy hosted it for free and its quite nice. I prefer it to Firebase because it felt like the API was simpler and more discoverable. I think the fact that no company is "pushing it along" means it stays simple.
But since they got acquired by MongoDB things have gone a bit quiet, so who knows?
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
- 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
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.
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)
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
More client libraries coming soon https://www.npmjs.com/package/@supabase/supabase-js
Look I get the sentiment, but you know what I mean. Graphql would be a killer feature.
I also haven't read something about authentication and validation. You can't compare a database without auth with firebase.
See my comment here: https://news.ycombinator.com/item?id=23319978
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?
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.
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!
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.
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.
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.
I'm not familiar with the project historically, as I've only been using it for about 2 months, but it seems to me like there's been an increase in activity since the start of the year - like the package modularization, new UI components, and new docs (which are still pretty bad to be honest). I totally agree it's sub-par to Firebase, and if you stray anywhere off the beaten path you're completely on your own (i.e. not using React, seemingly (!!)), but I do think it has the potential to become a viable alternative.
My primary issue with the platform is the choice of a NoSQL database, which, in my view, just doesn't match the majority of application requirements - if you want to do any sort of text search, you have to spin up a whole sodding Elasticsearch domain, which are expensive as hell for a new product and take literally 20-30 minutes every time they're updated with an `amplify push` command. I also waited over a week for one to be deleted not too long ago. That's why my plan is to replace the API with a Lambda function running Postgraphile with some JWK logic to use Cognito for authN, while keeping the idM and file storage stuff.
[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)
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
https://github.com/supabase/supabase/commit/c905edef57b4b1b0...
We will definitely come up with something better - suggestions welcome (taglines are hard)
https://supabase.io/docs/pricing/
I wonder what the "investors" mailing list is about.
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://auth0.com/
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.
What have you used instead of Auth0?
> 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-...)
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.
Check the person is who they say they are (authenticate), and then check they're allowed to access the thing they want to view (authorize).
The first is quite easy to abstract, the latter is basically custom to most applications (for different definitions of "custom").
Just thought you should know, when I read "Firebase alternative", I got excited about something else.
We have client libraries for PostgREST, which then gets installed as a dependency in our main client library.
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
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).
tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)
Then I saw that THIS was written in elixir.
That made me take this much more seriously!
Basically we are refactoring it so you can pipe your database changes anywhere - webhooks, kafka, serverless, slack etc
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
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.