Supabase if fast

So is firebase.

The difference is, firebase is amazing to prototype on and get an MVP out.

I have a table with around 40 million rows in it. With some sensible table partitions, indexes, and well-written queries as stored functions inside the DB, I have a latency of around 100-200ms on lookup (it might even be faster now, I've not tested it for a few months). It's plenty fast enough as long as you approach it correctly.

Then you gotta find a bank to take out a loan to pay for the bandwidth and over usage

Meanwhile, Supabase actually has predictable costs.

omg wow thanks for this

Note: don’t be me and fetch 4MB of data through PostgREST 😂

Kong is gonna cause some serious disk buffering and probably fail on the aws disk credits quota

isee

Are the docs for

Storage v2

already online? 😱

yea that happens with firebase too imean response time is pretty slow at first query idk why

sometimes*

I'd say this is one of the biggest deciding factors for many projects. Costs can be mostly ignored for smaller projects, but a good mindset to have is "What if I choose to scale this up to thousands of users?". That's where Firebase and such will start to catch you out, and you don't even have the option of self-hosting those, so the costs are unavoidable. I'd much rather pay $25 a month and know what I'm getting, than have to predict a bunch of unknowns, put them into a calculator form that's not exactly straightforward, and then hope I don't exceed my predictions.

Oh I was talking about actual failure with Supabase on large responses, not just delays.

Funny, the calculators for the big 3 never actually gave me any real value, ever lol

And that was for when I could actually estimate all the usages, which won’t be the case for a lot of projects.

ohisee is that issue solvable i mean with future updates

The Azure Cosmos one was the easiest, but it was still like 10x what I would pay for Supabase. My entire architecture costs less than just DB would on most other platforms

I mean, that issue isn’t really much of an issue. You shouldn’t be piping that much data through an API to begin with

Not sure if you want to extend auth.user table field. It's not possible for now. Had a discussion here. https://github.com/supabase/supabase/discussions/2345#discussioncomment-1015880

But yeah, Supabase is definitely a worthy alternative to Firebase - some would argue is much better.

mhm okay

It all depends on what you need. I need a database and I don't want to deal with devops/infrastructure. That's where Supabase comes in

yeah and self hostable

If you're needing to pipe large amounts of data, I believe the storage endpoint is the way to go. For example, if you've got a 'user uploads' section, create a bucket for that user, and then store the URL to the bucket in the user record (as opposed to storing blobs in the database)

@Lio wouldn't it theoretically be slow? cause it's a two-step process to hit the db

your app - ur backend - supabase - postgres db

Supabase -> pgsql is super fast

backend -> supabase can also be extremely fast depending on how you set up your thing region wise and infrastructure wise.