21–30 of 194 posts
Friendly reminder that Supabase is really cool, and if you haven't tried it out you should do it (everything can be self hosted and they have generous free tiers!)
Plus, with all the inflated vc money fueled hype on vector databases, they seem to have the only offering in this space that actually makes sense to me. With them you can store your embeddings close to all the rest of your data, in a single postgres db.
Dear supabase. Please don’t get bought out by anyone and ruined. I’ve built too many websites with a supabase backend now to go back.
we don't have any plans to get bought. we only have plans to keep pushing open standards/tools - hopefully we have enough of a track record here that it doesn't feel like lip service
You specifically say "for large files". What's your bandwidth and latency like for small files (e.g. 20-20480 bytes), and how does it compare to raw S3's bandwidth and latency for small files?
Generally, you would want to place an upload server to accept uploads from your customers, that is because you want to do some sort of file validation, access control or anything else once the file is uploaded. The nice thing is that we run Storage within the same AWS network, so the upload latency is as small as it can be.
In terms of serving files, we provide a CDN out-of-the-box for any files that you upload to Storage, minimising latencies geographically
You specifically say "for large files". What's your bandwidth and latency like for small files (e.g. 20-20480 bytes), and how does it compare to raw S3's bandwidth and latency for small files?
the only thing i can say related to the topic is that s3 multipart outperforms other methods for files larger than 50mb significantly, but tends to have similar or slightly slower speeds compared to s3 regular upload via supabase or simplest supabase storage upload for files with size about and less than 50mb.
s3-multipart is indeed the fastest way to upload file to supabase with speeds up to 100mb/s(115 even) for files>500mb. But for files about 5mb or less you are not going to need to change anything in your upload logic just for performance cause you won’t notice any difference probably
everything mentioned here is for upload only
Now we just need flutterflow to get off the firebase bandwagon.
I know Flutterflow's Firebase integration is a bit more polished so hopefully we can work closer with the FF team to make our integration more seamless
https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...
A question about implementation, is the data really stored in a Postgres database? Do you support transactional updates like atomically updating two files at once? Is there a Postgres storage backend optimized for storing large files?
We do not store the files in Postgres, the files are stored in a managed S3 bucket. We store the metadata of the objects and buckets in Postgres so that you can easily query it with SQL. You can also implement access control with RLS to allow access to certain resources. It is not currently possible to guarantee atomicity on 2 different file uploads since each file is uploaded on a single request, this seems a more h…
So this is like, S3 on top of S3? That's interesting.
The article does not mention: do you support pre-signed URLs? https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...