Supabase is the Postgres Development Platform and we are looking for Product Managers and Technical Program managers. You will be working with very strong Product Engineers across a wide variety of products (Postgres, realtime, storage, Queues, etc). If you enjoy working on developer tools and like to get your hands dirty, check out our open product roles
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.
We don't support S3 event notifications directly, but you achieve similar functionality by using Database Webhooks [1]. You can trigger any HTTP endpoint or a Supabase Edge function by adding a trigger to the objects table [3] in the Storage schema.
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].
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 more useful. In that scenario we would sync the metadata in the database to match what's actually being stored and if we notice metadata of a object missing, we add that in as opposed to deleting the object in storage. This would make it easier for you to bring in your own s3 bucket with existing data and attach it to Supabase storage.
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.
This release brings resumable uploads to Storage. If you users are uploading large files or uploading from a mobile network, this improves the user experience by continuing the upload from exactly where it was interrupted. As a side benefit, you also get progress events exposed in a neat way.
And we continue to use more of Postgres. We use it as a database to store object metadata, RLS policies for Authorization[1], the SKIP Locked feature for building a queue [2] and advisory locks for implementing a distributed locking mechanism [3].
Added a comment in the discussion [1] with a video and a quickstart guide on how you can configure VSCode to work with Deno. Let's continue the discussion there in case those steps don't work for you.
With respect to supporting other runtimes, it mostly comes down to focussing on providing a great experience with one runtime first. And based on your feedback, we still have some work to do there.
We use Kong as our API Gateway, so it is responsible for authentication, rate limiting, routing, etc. By moving that to edge runtime, we simplify our stack since we already run a edge runtime container to run user functions.
The other motivation for doing this is that it makes our API Gateway programmable with user defined functions. For example, you could implement custom transformations for storage or augment the Authorization header with custom claims before calling Postgrest.
We currently block HTML responses on Functions and Storage, but we are considering relaxing that limitation, so that you can host static sites on our Storage. And allowing user-defined functions running on every request to Storage in the edge runtime would get you the reverse proxy logic you are looking for.
One reason is that Deno can run on v8 isolates which start up really quickly. This makes the deploys near instantaneous and helps with cold start time too. The DX with Deno is pretty neat since it comes in bundled with a test runner, doc generator, linter, bundler, etc.
We are planning to focus on the Deno and WASM ecosystem. If C# complies to WASM, we would be able to run it, but have a lot of work to do to make this seamless.
This is a webserver built on the Deno runtime. Deno makes it easy to build a custom JavaScript runtime [1]. I am excited about extending this runtime to integrate it better with the rest of the Supabase stack. For example, we can modify the Deno filesystem API to read and write files to Supabase Storage instead.
Supabase is the Postgres Development Platform and we are looking for Product Managers and Technical Program managers. You will be working with very strong Product Engineers across a wide variety of products (Postgres, realtime, storage, Queues, etc). If you enjoy working on developer tools and like to get your hands dirty, check out our open product roles
- Product Manager https://jobs.ashbyhq.com/supabase/74542052-f648-48fb-a8fe-a8...
- Technical Program Manager https://jobs.ashbyhq.com/supabase/b83c7316-77ce-49a8-a199-9f...
We are also hiring for other engineering and growth roles - https://supabase.com/careers