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

Supabase Storage now supports the S3 protocol

supabase.com

Post reply on HN
Print view View original

151–160 of 194 posts

Re: Supabase Storage now supports the S3 protocol

#151

Post by beachy »

vbezhenar wrote: post #146
Rapzid wrote: post #57

I like to Lob my BLOBs into PG's storage. You need that 1-2TB of RDS storage for the IOPS anyway; might as well fill it up. Large object crew, who's with me?!

I don't. S3-compatible storages usually are significantly cheaper, allow to offload HTTP requests. Also huge databases make backups and recoveries slow. The only upside of storing blobs in the database is transactional semantics. Buf if you're fine with some theoretical trash in S3, that's trivially implemented with proper ordering.

> The only upside of storing blobs in the database is transactional semantics.

Plenty more advantages than that. E.g for SaaS you can deep copy an entire tenant including their digital assets. Much easier copying with just "insert into ... Select from" than having to copy S3 objects.

Re: Supabase Storage now supports the S3 protocol

#152

Post by zipping1549 »

yoavm wrote: post #36

This looks great! How easy is it to self host Supabase? Is it more like "we're open-source, but good luck getting this deployed!", or can someone really build on Supabase and if things get a little too expensive it's easy enough to self-host the whole thing and just switch over? I wonder if people are doing that.

Some may disagree but in my experience Supabase was definitely challenging to selfhost. Don't get me wrong; I'm pretty confident with selfhosting but Supabase was definitely on the hard side.

Pocketbase being literally single-binary doesn't make Supabase look good either, although funtionalities differ.

Re: Supabase Storage now supports the S3 protocol

#153

Post by josephd79 »

hacker_88 wrote: post #123
gherkinnn wrote: post #34

Earlier quoted context omitted.

This is my biggest reservation towards Supabase. Google bought Firebase in 2014. I've seen Vercel run Nextjs in to the ground and fuck up their pricing for some short-term gains. And Figma almost got bought by Adobe. I have a hard time trusting products with heavy VC backing.

Wasn't there Parse from firebase

Parse was bought by Facebook and not much longer shut it down right?

Re: Supabase Storage now supports the S3 protocol

#154

Post by kiwicopple »

replwoacause wrote: post #144
kiwicopple wrote: post #136

Earlier quoted context omitted.

> neutered Can you share more? There is nothing missing, it’s all the same code that we run in production (besides some login changes to keep it decoupled from the platform)

Sure. I wouldn't quite agree with you that "there is nothing missing" though. https://github.com/orgs/supabase/discussions/4444 https://github.com/orgs/supabase/discussions/4421

thanks for the links

> https://github.com/orgs/supabase/discussions/4444

This discussion is about configuration: self-hosters configure configure their services in code[0], using .env vars / docker-compose.yml and should be checking it into source control. Self-hosters are not missing any functionality - the opposite actually: we have a subset of configuration items available on the platform

I get that it's different to the platform, but it's (IMO) the more "correct" way - all configuration should be version controlled

> https://github.com/orgs/supabase/discussions/4421

This one is about Auth providers. They are also configuration: https://github.com/supabase/auth?tab=readme-ov-file#configur...

[0] Configuration in code: https://supabase.com/docs/guides/self-hosting/docker#configu...

[1] Terraform: https://supabase.com/docs/guides/platform/terraform

Re: Supabase Storage now supports the S3 protocol

#155

Post by kiwicopple »

mattgreenrocks wrote: post #94

Just commenting to say I really appreciate your business model. Whereas most businesses actively seek to build moats to maintain competitive advantage and locking people in, actions like this paint a different picture of Supabase. I'll be swapping out the API my app uses for Supabase storage to switch it to an S3 API this weekend in case I ever need to switch it. My only real qualm at this point is mapping JS entitie…

> mapping JS entities using the JS DB API makes it hard to use camelcase field names due to PG reasons I can't recall

Postgres requires you to "quoteCamelCase". There are some good JS libs to map between snake case and camel case. FWIW, I like a mix of both in my code: snake_case indicates it's a database property, and camelCase indicates its a JS property. Try it out - it might grow on you :)

Re: Supabase Storage now supports the S3 protocol

#157

Post by hobs »

inian wrote: post #148
tln wrote: post #133

Earlier quoted context omitted.

Will the files get deleted with ON CASCADE DELETE somehow? That would be awesome. Then for GDPR, when you delete a user, the associated storage can be deleted. One could cobble this together with triggers, some kind of external process, and probably repetititious code so there is one table of metadata per "owning" id, although it would be nice to be packaged.

We have discussed this internally before since we have seen some users delete the metadata in the storage schema and expect the underlying object to be deleted too and if we should convert our entire storage server to just be a Postgres extension. The source of truth also matters here - if it's the database or the underlying s3 bucket. I think having the underlying storage bucket to be the source of truth would be mo…

This falls in line with how SQL Server did its FileStream stuff, but it was so clunky nobody used it except for some madmen.

Re: Supabase Storage now supports the S3 protocol

#158

Post by pier25 »

inian wrote: post #147
pier25 wrote: post #145

At $0.1/GB of egress it’s not super attractive compared to B2 or R2 for anything but trivial projects. I wish they would offer a plan with just the pg database. Any news on pricing of Fly PG?

We are hosted on aws and are just passing the cost over to our users. We make no margin on egress fees. Deploying storage on other clouds including Fly.io is planned. We are actively working on our Fly integration. At the start, the pricing is going to be exactly the same as our hosted platform on aws - https://supabase.com/docs/guides/platform/fly-postgres#prici...

Thanks. So a user that only wants pg has to pay for storage etc?

Re: Supabase Storage now supports the S3 protocol

#159

Post by ezekg »

Havoc wrote: post #156

What are the chances of Supabase doing a license change? Seems to be fashionable these days so always a little wary of building on these sort of platforms

Seeing as Neon, Nile, Citus, etc. are all open source, I highly doubt it. But who knows. In the end, most license changes are blown out of proportion by a vocal minority and largely have zero effect on 99.9% of users.

Re: Supabase Storage now supports the S3 protocol

#160

Post by mdaniel »

beachy wrote: post #151
vbezhenar wrote: post #146

Earlier quoted context omitted.

I don't. S3-compatible storages usually are significantly cheaper, allow to offload HTTP requests. Also huge databases make backups and recoveries slow. The only upside of storing blobs in the database is transactional semantics. Buf if you're fine with some theoretical trash in S3, that's trivially implemented with proper ordering.

> The only upside of storing blobs in the database is transactional semantics. Plenty more advantages than that. E.g for SaaS you can deep copy an entire tenant including their digital assets. Much easier copying with just "insert into ... Select from" than having to copy S3 objects.

Or the opposite side of that, deletion. Pruning 38TB worth of S3 would be an unholy exercise unless the keys are 1TB each. I am aware of Lifecycle Policies, but they are a gargantuan PITA, IMHO
Post reply on HN