Live data from Hacker News

Supabase (YC S20) – An open source Firebase alternative

supabase.io

311–320 of 374 posts

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

#311

Earlier quoted context omitted.

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.

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

Are you serious?

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

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

#312

Earlier quoted context omitted.

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

What I was trying to say is that I was anticipating having to write and maintain a bunch of glue between firebase and these tools and maybe eventually outgrowing this glue.

A benefit of using a traditional SQL database is much of this stuff exists already off the shelf.

Maybe Firebase is there or is getting there. It's almost two years since I built something on it.

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

#313
post #53

Earlier quoted context omitted.

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

thought parse died a while ago with fb?

In some ways it was born when that happened :-).

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.

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

#314

Earlier quoted context omitted.

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.

Former Firebase and Parse employee. Back when Parse was coincidentally working on GCM (aka FCM) support to improve reliability over our own blocking-socket push network Google threatened to shut down our customers if they used our network. I personally liked our approach which used our network in China and Google elsewhere. I would believe Google were just concerned with Android quality, except our customers reported that they were being scraped from meetup lists, interviewed, and told that Facebook was pricing Parse low to steal data from our users.

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

#315
post #302

Earlier quoted context omitted.

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.

Wow that is pretty bleak actually. 500ms+ in a world where edge cached serves at 5ms def means one needs to deploy these strategically only

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

#316

Earlier quoted context omitted.

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…

If you would like to explore more TypeScript ORM Libraries TypeORM comes to mind, and recently Zapatos made it into the frontpage and although it's new it looks like a nice simple but powerful alternative, much more close to raw SQL than TypeORM's clearly abstract layer/magic sause. just my 2 cents Also about more general web frameworks like rails and not ORM's I personally use NextJS with TypeScript, like Ant.Design…

Thank you. I have been eyeing NextJS quite seriously. I'll be needing to build a non-trivial frontend application pretty soon and I've been really wondering if I should got the NextJS route.

Have you used it with a big app?

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

#317
post #154

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.

If you've built your business so it is dependent on someone else's pricing model the problem is of your own making.

Think you’ll have a hard time building a business without being dependent on a suppliers Pricing model

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

#318

Earlier quoted context omitted.

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.

We went quickly from "Why shouldn't they charge for a great product?" to "they deliberately toasted competing solutions by creating a white-list with only their own."

Admittedly, some other solutions were shitty and ate into the battery, but this wasn't the case for everything and forcing everyone onto a proprietary platform if they need an always connected background service is not "a great product," but a defective one.

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

#319
post #291

Earlier quoted context omitted.

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

Just that if two people make changes at the same time on different clients, I don't have much control over merging those changes together with Firebase (that I know of). I think it's just a "last change wins" type system.

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

#320
post #203

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.

> Fees should based on OUR revenue, not usage.

So if someone builds a business that makes very little money but uses a ton of compute, the cloud provider should subsidize that? And conversely if you make a ton of money using barely any compute, you should pay your cloud provider a premium? This business model makes no sense.

Post reply on HN