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

301–310 of 374 posts

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

#301

Post by agustif »

time0ut wrote: post #236
ta17711771 wrote: post #207

Earlier quoted context omitted.

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…

You can leverage Postgres full-text search, and GeoJSON/PostGIS support. Also for replacing algolia ElasticSearch comes to mind, that should work for most of those use cases.

For analytics and in the SaaS part you have both mixpanel and segment, and also some nice privacy-aware alternatives to Google analytics like fathom and some other indie startup.

Recently some open source segment alternative came along in HN...

MS PowerBI connects with lots of stuff, although it's paid ELK is open source Also metabase is a nice open source tool for BI.

Lots of tools!

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

#302

Post by pier25 »

davidb_ wrote: post #299
pier25 wrote: post #279

Earlier quoted context omitted.

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

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 The specific issue I was running into: https://github.com/googleapis/google-cloud-node/issues/2942

Check this benchmark:

https://serverless-benchmark.com/

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

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

#303

Post by tirumaraiselvan »

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.

We have this feature high up in our priority: https://github.com/hasura/graphql-engine/issues/1514

We already support user defined PG functions to be exposed as graphql queries so this is a natural extension.

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

#304

Post by mav3rick »

bawana wrote: post #203
nicoburns wrote: post #121

Earlier quoted context omitted.

No, when they tout the product as free or cheap, and then only later up the pricing by 10x, once people have built their business around the older pricing model. That's a problem.

The pseudo-democratic silicon valley model of freemium is the problem. Seducing you into using something with the word 'free' but then trapping you with a changing API and cost structure. They should be up front with the realization that our ability to pay THEM is not commensurate with use by OUR users. Fees should based on OUR revenue, not usage.

This is not a charity

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

#305

Post by mav3rick »

sparkie wrote: post #190
Tostino wrote: post #172

Earlier quoted context omitted.

Couldn't agree more. If major price changes are required to make the product work well after customers have been "enticed" in with a reasonable cost, it is underhanded to say the least.

It's more than just "entice". Google has crippled apps which don't use FCM since Oreo by limiting their ability to run alternatives which have a blocking socket waiting for new information. Only choice is to use FCM or lose essential functionality.

FCM is part of the core API now. They don't want other shitty solutions constantly waking the device up and eating your battery. That is why only FCM i.e. a trusted source is white listed. It's easy to peddle half truths hear just give it an anti Google color and carry your pitch forks.

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

#306

Post by rhlsthrm »

BiteCode_dev wrote: post #151
rhlsthrm wrote: post #134

Earlier quoted context omitted.

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

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.

Right but the idea is I'm trying to approach it from the front end and define the schema using the GraphQL queries which the front end will use.

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

#307

Post by xenospn »

davidb_ wrote: post #299
pier25 wrote: post #279

Earlier quoted context omitted.

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

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 The specific issue I was running into: https://github.com/googleapis/google-cloud-node/issues/2942

I'm still getting regular 15-20 second cold starts.

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

#308

Post by rhlsthrm »

electriclove wrote: post #178
rhlsthrm wrote: post #134

Earlier quoted context omitted.

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

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

This looks really interesting thanks for sharing.

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

#309

Post by carlps »

bavell wrote: post #185
RNCTX wrote: post #179

Earlier quoted context omitted.

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

What are the pros/cons of using entirely different (siloed) databases with uniform permissions instead of a single database supporting granular permissions? Off the top of my head, I'd say security might be improved but ease of use may suffer. Interested in hearing other's thoughts on the matter.

The cons are inumerable. We've been down that road before and the whole world of business intelligence and enterprise data warehousing came out of it. When every functional unit has their own db, how do you answer questions of the business as a whole? How do you deal with data that multiple functional areas need? On top of that, managing a lot of small silos requires a lot more work and resources then the alternative.

Eventually you're going to want to bring that data all together and now you have to have data architects and engineers developing etl solutions and then your resulting data warehouse is going to be that singular database you were trying to avoid from the start, with all the overhead of building it and maintaining it on top of all the maintenance of the source silos.

See https://en.wikipedia.org/wiki/Data_warehouse

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

#310

Post by LunaSea »

fwoty wrote: post #291
kiwicopple wrote: post #186

Earlier quoted context omitted.

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

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

Could you expand on what you mean by "conflict resolution"?
Post reply on HN