Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase (YC S20) – An open source Firebase alternative

supabase.io

Post reply on HN
Print view View original

231–240 of 374 posts

Re: Supabase (YC S20) – An open source Firebase alternative

#231

Post by nick-garfield »

tluyben2 wrote: post #108
godzillabrennus wrote: post #77

Earlier quoted context omitted.

Any thoughts on Auth0? https://auth0.com/

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.

I agree with this. I think Auth0 at one point was building tools for indie devs, but are now focused mostly on enterprises.

What have you used instead of Auth0?

Re: Supabase (YC S20) – An open source Firebase alternative

#232

Post by mauflows »

midrus wrote: post #215
grizzles wrote: post #211

Earlier quoted context omitted.

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

That's pretty close to the pouchdb + (couchdb|cloudant) combo...

If pouchdb was better maintained I feel like it would be much more popular. IBM should really sponsor it considering they even list it as a cloudant client

Re: Supabase (YC S20) – An open source Firebase alternative

#233

Post by kiwicopple »

treis wrote: post #226
kiwicopple wrote: post #205

Earlier quoted context omitted.

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)

How do you handle the creation of the database for a new user? Any issues with maxing out connections to the DB?

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

> Any issues with maxing out connections to the DB?

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

Re: Supabase (YC S20) – An open source Firebase alternative

#234

Post by freedomben »

eatonphil wrote: post #176
halfdan wrote: post #174

Earlier quoted context omitted.

Ruby in Rails has this as a feature called "scaffold". https://www.rubyguides.com/2020/03/rails-scaffolding/

Rails is probably one of the best ways to not waste time. I knew they had some of this capability but I wasn't sure if they generated the whole controller, fully hooked up to the models, too. The only thing that turns me off about Rails and .NET is that it's a big learning curve _because_ the projects are so feature complete. Since I haven't worked professionally in either of them, I haven't been able to get myself t…

Agreed, this is a real problem. I recently did a test. I have about a year of rails experience but it was so long ago that I forgot most things and had to look them up. I also wrote quite a bit of node/express but it was in the node 0.10 days so I had a lot of catch-up to do.

I started a new app and I got a basic Users and Sessions model with endpoints running (I like this test because dealing with passwords and API tokens requires writing some code instead of generating it all, but also leverages libraries).

These numbers aren't useful by themselves since you don't know the details of the work I did, but they may be useful side by side:

Express/TypeScript: Took me about 24 to 30 hours to get it all implemented. I started with no ORM (node-postgres) then tried out Knex, then settled on Slonik.js. Because of that I had to re-write some stuff a few times. However, in a bare-bones "framework" this is part of the penalty.

Rails: Took about 10 hours (mostly reading documentation and Michael Hartl's book).

I think I prefer the Node approach simply because I know exactly what is going on under that hood. That said however, if I were a second developer coming into the code base I'd prefer the Rails approach because I'd have to learn "the framework" anyway and a widespread standardized one like Rails would be preferable to learn IMHO.

In conclusion: My numbers are highly individualized and don't tell the whole story of course. In related news, I actually threw both of them away and went back to Elixir/Phoenix, my third love. I'm quite happy there at the moment, and I don't anticipate moving again.

Re: Supabase (YC S20) – An open source Firebase alternative

#235

Post by gbourne »

kiwicopple wrote: post #186
habosa wrote: post #149

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…

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

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.

Re: Supabase (YC S20) – An open source Firebase alternative

#236

Post by time0ut »

ta17711771 wrote: post #207
time0ut wrote: post #164

Earlier quoted context omitted.

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…

I've seen this sentiment echoed a few times. What are the advantages, or class of advantages, you get by moving on from Firebase to something stronger/harder?

I expect that our business logic would eventually have outgrown rules and cloud functions.

We used algolia to do full text and geo search. It worked, but I expected eventually it'd be really painful to reindex.

Same sort of thing with analytics. Firebase analytics is pretty powerful, but eventually we would want all our data mirrored somewhere we could use regular BI tools.

Then there is cost. We would have to weigh the cost of rewriting against the GCP bill, but at some point I expect it'd make sense.

Take this all with a grain of salt. We didn't get far enough to test any of these assumptions.

Re: Supabase (YC S20) – An open source Firebase alternative

#238

Post by eatonphil »

z3t4 wrote: post #229
eatonphil wrote: post #165

Earlier quoted context omitted.

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…

Who does the same app over and over, and if then why not just copy it? With new tech there are a lot of churn, who knows Google will announce the shutdown of the db service tommorow, and next week you need to rewrite the app in the latest version of the framework. Meanwhile old boring tech will still work just fine 20 years from now.

I can't copy code I wrote at the previous employer. It's best to learn and stick to a framework, or write something yourself once you can steal from. I'm doing the latter with code generation.

Re: Supabase (YC S20) – An open source Firebase alternative

#239

Post by edraferi »

skrtskrt wrote: post #195
eatonphil wrote: post #165

Earlier quoted context omitted.

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…

To me there's a sliding scale between productivity, where you use a heavy framework like Django and Rails to do everything for you, and control, where you write boilerplate to stitch all your favorite single-purpose libraries together using your preferred patterns. They each have their purposes. Django will get you to market fast with all the features you need, and keep you there for a long time. But it forces (throu…

Can you provide a more detailed critique of Django’s “Fat Models” recommendation? How would you prefer to manage this logic?

Re: Supabase (YC S20) – An open source Firebase alternative

#240

Post by cpursley »

PKop wrote: post #184
praveenweb wrote: post #37

Earlier quoted context omitted.

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 hoste…

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.

I believe Hasura is working towards being able to write Actions in SQL.

How are you surfacing RPCs from the database? That sounds interesting.

Post reply on HN