inian

Joined 12 years ago

Karma

993

Submissions

173

Member since

Oct 6

Supabase Engineer (https://supabase.com)

View on Hacker News

Recent submissions

Comment · 1 year ago

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

Comment · 2 years ago

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

Comment · 2 years ago

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

Comment · 2 years ago

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

Comment · 2 years ago

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

Comment · 2 years ago

There is no per request pricing.

Comment · 2 years ago

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!

Comment · 2 years ago

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.

Comment · 2 years ago