Live data from Hacker News

Supabase Storage now supports the S3 protocol

supabase.com

81–90 of 194 posts

Re: Supabase Storage now supports the S3 protocol

#81
post #72

Always thought it’s kind of odd how the proprietary API of AWS S3 became sort of the de-facto industry standard

Because that's where most of the industry store their data.

Yeah I understand how it came to be, it’s just kind of an uncommon situation

Re: Supabase Storage now supports the S3 protocol

#82

Earlier quoted context omitted.

I think Vercel and Next.js are built by the same group of people, the same people who made Now.sh, started the company (Zeit), then changed product name to Now.sh, then changed company and product name to Vercel.

Yes. That doesn’t mean that they haven’t ran it into the ground.

Tell me about it.

My simple SSG Next.js static site loads much slower than my Jekyll site on GitHub pages.

And I can't figure out how to improve its speed or disable the "ISG" feature that I believe is to be blamed for the poor performance.

Re: Supabase Storage now supports the S3 protocol

#83
post #48

Earlier quoted context omitted.

What about for second tier cloud providers like Linode, Vultr or UpCloud, they all offer S3 compatible object storage, will I need to write an adaptor for these or will it work just fine in lieu of their S3 compatibility?

Our S3 Driver is compatible with any S3 Compatible object Storage so you don’t have to write one :)

I’m confused about what directions this goes.

The announcement is that Supabase now supports (user) —s3 protocol—> (Supabase)

Above you say that (Supabase) —Supabase S3 Driver—> (AWS S3)

Are you further saying that that (Supabase) —Supabase S3 Driver—> (any S3 compatible storage provider) ? If so, how does the user configure that?

It seems more likely that you mean that for any application with the architecture (user) —s3 protocol—> (any S3 compatible storage provider), Supabase can now be swapped in as that storage target.

Re: Supabase Storage now supports the S3 protocol

#85

Earlier quoted context omitted.

Yes. That doesn’t mean that they haven’t ran it into the ground.

Tell me about it. My simple SSG Next.js static site loads much slower than my Jekyll site on GitHub pages. And I can't figure out how to improve its speed or disable the "ISG" feature that I believe is to be blamed for the poor performance.

Not defending NextJS, I'm pretty out on it myself, but ISG requires a server to run. It pregenerates static content for defined pages and serves that until revalidating. If you've built a fully static bundle, nothing exists that would handle that incremental/revalidating logic.

Re: Supabase Storage now supports the S3 protocol

#87

Earlier quoted context omitted.

are there any specific integrations that you want? (eg: which companies?) we have a built-in CDN[0] and we have some existing integrations for transactional emails [1] [0] Smart CDN: https://supabase.com/docs/guides/storage/cdn/smart-cdn [1] Integrations: https://supabase.com/partners/integrations

Thanks for the link about integrations! I wasn't aware about the resend one for transactional email. It'd be nice to have an integration with a domain register, like Ghandi.net or Namecheap. Ideally with the cost coming through as an item in my Supabase bill.

Thanks for the recommendations - I’ll see what this would involve

Re: Supabase Storage now supports the S3 protocol

#88
post #48

Earlier quoted context omitted.

What about for second tier cloud providers like Linode, Vultr or UpCloud, they all offer S3 compatible object storage, will I need to write an adaptor for these or will it work just fine in lieu of their S3 compatibility?

Our S3 Driver is compatible with any S3 Compatible object Storage so you don’t have to write one :)

Gentle reminder here that S3 compatability is a sliding window and without further couching of the term it’s more of a marketing term than anything for vendors. What do I mean by this statement? I mean that you can go to cloud vendor Foo and they can tell you they offer s3 compatible api’s or clients but then you find out they only support the most basic of operations, like 30% of the API. Vendor Bar might support 50% of the api and Baz 80%.

In a lot of cases, if your use case is simple, 30% is enough if you’re doing the most common GET and PUT operations etc. But all it takes is one unsupported call in your desired workflow to rule out that vendor as an option until such time that said API is supported. My main beef with this is that there’s no easy way to tell usually unless the vendor provides a support matrix that you have to map to the operations you need, like this: https://docs.storj.io/dcs/api/s3/s3-compatibility. If no such matrix is provided on both the client side and server side you have no easy way to tell if it will even work without wiring things in and attempting to actually execute the code.

One thing to note is that it’s quite unrealistic for vendors to strive for 100% compat - there’s some AWS specific stuff in the API that will basically never be relevant for anyone other than AWS. But the current situation of Wild West could stand for some significant improvement

Re: Supabase Storage now supports the S3 protocol

#89
post #3

Here is the example of the DuckDB querying parquet files directly from Storage because it supports the S3 protocol now - https://github.com/TylerHillery/supabase-storage-duckdb-demo https://www.youtube.com/watch?v=diL00ZZ-q50

Yes. Duckdb works very well with parquet scans on s3 right now.

Re: Supabase Storage now supports the S3 protocol

#90

no feedback on this in particular, but I love supabase. I use it for several projects and it's been great. I was hesitant to use triggers and PG functions initially, but after I got my migrations sorted out, it's been pretty awesome.

Do you manage your functions and triggers through source code? What framework do you use to do that? I like Supabase but it’s desire to default to native pg stuff for a lot of that has kind of steered me away from using it for more complex projects where you need to use sprocs to retrieve data and pgtap to test them, because hiding away business logic in the db like that is viewed as an anti pattern in a lot of organizations. I love it for simple CRUD apps though, the kind where the default postgrest functionality is mostly enough and having to drop into a sproc or build a view is rarely necessary.

I think if there was a tightly integrated framework for managing the state of all of these various triggers, views, functions and sproc through source and integrating them into the normal SDLC it would be a more appealing sell for complex projects

Post reply on HN