181–190 of 194 posts
Is there a formal s3 protocol spec or do these companies try to reverse engineer/feature match what AWS provides?
The S3 API reference [1] is closest to a formal spec there is. The request, response and the error codes are pretty well documented. [1]: https://docs.aws.amazon.com/AmazonS3/latest/API/API_Operatio...
Earlier quoted context omitted.
I believe that the self hosted version is missing auth hooks. https://www.reddit.com/r/Supabase/comments/1bpaq9w/comment/k...
i believe the docker image ID on the docker-compose hasn’t been updated to the latest stable version. I’ll make a PR later when I’m at my computer (or anyone else is welcome to and I can review/merge)
Earlier quoted context omitted.
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 organ…
The Supabase CLI [1] provides a way for you to manage functions, triggers and anything else in your Postgres database as a migration. These migrations would be checked into your source control. You can then take it a step further but opting-in to use Branching [2] to better manage environments. We just opened up the Branching feature to everyone [3]. [1]: https://supabase.com/docs/guides/cli/local-development#datab..…
Let’s say that we are using the Typescript sdk to make our app and need to do some fancy aggregation on a table that isn’t supported by Postgrest natively (specifically we can’t retrieve the data with Postgrest out of the box with its typical setup). Postgrest tells us that in this case we can do two things: create a view or make a Postgres function. Each has their pros and cons, but with either choice now we have this problem: some of our business logic is in sproc/function/view and some of it is in Typescript. In a typical setup using an ORM it would all be in Typescript.
The conventional wisdom is that db’s are dumb state holders and all of the business logic goes in the app - Supabase attempts to turn this on its head and say no actually it’s ok to store business logic in the db. But now if we do that we have a new problem: we don’t have a blessed path forward for where the line is on what goes where anymore. We don’t have good patterns for storing and managing this so other developers understand where to put things and how to work with our app anymore, because it no longer holds the principle of least astonishment. That’s what I mean by framework in this context.
Maybe all that is necessary here is a battle tested example project that demonstrates the “correct” way to make this demarcation. But as-is it steers me away from using Supabase for more complex projects if I even think they will need something that Postgrest won’t support without making a view or sproc/function
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.
Earlier quoted context omitted.
38TB of large objects stored in Postgres right here
A hero appears! The client I use currently, npgsql, supports proper streaming so I've created a FS->BLOB->PG storage abstraction. Streamy, dreamy goodness. McStreamy.
Earlier quoted context omitted.
A hero appears! The client I use currently, npgsql, supports proper streaming so I've created a FS->BLOB->PG storage abstraction. Streamy, dreamy goodness. McStreamy.
I am confused and curious. Can you please elaborate on how streaming is related to pg storage?
You CAN stream bytea but:
* Good luck finding a client that supports it(npgsql does actually)
* It doesn't support support start the read/write at any location other than the start. So you'd have to basically build the Lob(Large Object) functionality yourself on top to support upload resume and other use cases.
With Lob even if your client doesn't support streaming, you can mimick it by writing chunks into the Lob.
Earlier quoted context omitted.
i believe the docker image ID on the docker-compose hasn’t been updated to the latest stable version. I’ll make a PR later when I’m at my computer (or anyone else is welcome to and I can review/merge)
Awesome, thanks for following up and for making a great product!
There are some guides for using this in the CLI docs:
https://supabase.com/docs/guides/auth/auth-hooks#local-devel...
(I'll find a way to consolidate these docs so the work across CLI + docker-compose)
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
That said, I think Supabase is much more de-risked from this happening because we aim to support existing tools with a strong preference of tools that are controlled by foundations rather than commercial entities. For example, 2 of the main tools:
- Postgres (PostgreSQL license)
- PostgREST (MIT license)
Every tool/library/extension that we develop and release ourselves is either MIT, Apache2, or PostgreSQL
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.
I doubt we can ever squeeze the "supabase stack" into a single binary. This undoubtedly makes things more difficult for self-hosters. Just self-hosting Postgres can be a challenge for many. We will trying to make it easier, but it will never be as simple as Pocketbase.
[0] https://supabase.com/docs/guides/getting-started/architectur...
One of the big wins we get from AWS is that you can do things like load structured data files (csv, parquet) from S3 directly in Redshift using SQL queries. https://docs.aws.amazon.com/redshift/latest/dg/t_loading-tab...
This is indeed pretty cool. They also have the `aws_s3` extension [1] for doing the same thing inside Postgres. Unfortunately, the extension isn't open source. [1]: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_...