inian

Supabase | https://supabase.com/ | Remote

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

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_...

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.

[1]: https://supabase.com/docs/guides/database/webhooks [2]: https://supabase.com/docs/guides/functions [3]: https://supabase.com/docs/guides/storage/schema/design

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... [2]: https://supabase.com/docs/guides/platform/branching [3]: https://supabase.com/blog/branching-publicly-available

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...

There is no per request pricing.

I agree that s3 compatibility is a bit of a moving target and we would not implement any of the AWS specific actions.

We are transparent with what's the level of compatibility - https://supabase.com/docs/guides/storage/s3/compatibility

The most often used APIs are covered but if something is missing, let me know!

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.

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...

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

We hire the lead maintainer for PostgREST Steve [1] to primarily work on PostgREST since it’s a core part of the Supabase stack as you mentioned

[1] https://github.com/steve-chavez

Yeah the Typescript port gave a good starting point. However there were some missing pieces which we had to build into our server - https://github.com/tus/tus-node-server#extensions

We plan to contribute these back to the Node TUS server after launch week.

Hello HN, Supabase Engineer here.

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].

Will be hanging around to answer any questions.

[1] https://supabase.com/docs/guides/storage/access-control

[2] https://www.2ndquadrant.com/en/blog/what-is-select-skip-lock...

[3] https://supabase.com/blog/storage-v3-resumable-uploads#enter...

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.

[1] https://github.com/orgs/supabase/discussions/8779#discussion...

Can you share some examples where the tooling fell short?

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.

Hi, Supabase engineer here.

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.

[1] https://deno.com/blog/roll-your-own-javascript-runtime

Thank you! We will be working on video after we implement more image transformations. What is your usecase for audio and what transformations would you like to see?

Yes! If you resize your images correctly, your users use lesser data to load assets from Storage. A side benefit is you will be paying us lesser in egress fees.

We use imgproxy[1] for doing the resizing. We utilize open source services for the entire stack, so that you can self-host Supabase.

[1] https://github.com/imgproxy/imgproxy

Supabase Engineer here

There were a lot of primitives we built to ship image resizing - Storage events exposed via webhooks, rate limiting, a queue on top of Postgres, a smart CDN cache, object metadata endpoints, etc. These are already available if you are self hosting Supabase Storage, so that you can integrate your own CDN, listen to storage events, etc. Over the next few months, we will be working on exposing these on the Supabase platform too.

Looks like Dart doesn't support Wasm as a target yet but is considering it as part of their 2022 roadmap[0]. In the mean time, we will start off with supporting other languages like Rust which already have good support for compiling to Rust.

[0] Wasm target for Dart - https://github.com/dart-lang/sdk/issues/32894#issuecomment-1...

We can look at offering an option to restrict edge functions to just launch in the same region as your database (probably can't call it "edge" at that point though). This might also be useful if you are processing data in your function that you do not want to leave a particular geographical region.

We are also exploring running Deno directly inside your database - https://github.com/supabase/postgres-deno

If you are using Firebase Functions, it should be easy to port it over to Supabase Edge Functions. We also offer a Realtime database (Postgres), Auth and Storage as part of our stack.