This is the third big release this week (along with a Postgres Pooler and a Logging Server).

If you're wondering why there are so many, we generally "build for three months" then do all of our big product announcements in a "Launch Week". We're 2 days into this Launch Week so there will be a few more releases to come.

These all look really interesting. How do you pick what to make next?

Usually the teams know what they need to build based on user feedback (which we get a lot of).

We don't have Product Managers, the developers are expected to be very product-focused and user-facing. After every launch week we ask them what they want to build and then they get to work.

Hi! Congratulations on the launch. I'm a big fan of what you folks are doing over there and I genuinely love your product.

Would love to keep in touch to see when the changes to this will happen. Also speaking as a ceo & founder, my natural inclination is to keep that culture going, small and avoid hiring a PM as long as possible. As I reflect on my operating time, I wonder if it was a mistake not to find the right Product Manager (sic) early so that they can be inoculated with the culture as we grow. My estimation is that the ramp time for this would be at least 6 months (a year?) to have that future product manager operate with the same founding ethos.

Lmk if you're open to chatting about it. I'm honestly super curious.

> wonder if it was a mistake not to find the right Product Manager (sic) early so that they can be inoculated with the culture as we grow.

That's an interesting thought. We do have some techies "acting" as PMs across the team, but i can see how we might one a dedicated person at some point.

always open to chatting to other founders - feel free to reach out.

Interesting. I've never worked in a completely tech-led company before, but it seems like a good approach. My philosophy on it has changed a little: I used to think PM should be embedded in technical teams writing tickets, à la Scrum Product Owners, but now I think things function better when the team writes its tickets, and the PM works at a more general level: features, direction, marketing, legal, regulatory, etc etc.

That sounds like heaven. And you guys are using Rust! That’s like, double heaven!

Are you guys hiring ;)

we hire very slowly: when we have a problem to solve and nobody is owning the problem in the current team, we write a job spec specifically for this role and hire someone.

At the moment we don't have any Rust jobs, but we always you can keep an eye on supabase.com/careers or follow us on twitter to keep updated

HIPAA support this week? :)

We got SOC2 Type 2 last week, HIPAA is next.

We won't do much of an announcement about SOC2, so you can consider this comment the "official announcement" :)

Having been through the pain of SOC2 Type 2, I'll consider this a big announcement as well!

What’s soc2

I can't seem to find info about a postgres pooler release this week, where am I missing it?

Edit: never fails, you ask a question and then you immediately find it. https://news.ycombinator.com/item?id=35501718

I think this is great, but a growing question in my mind from these is what is the long tail plan for maintenance of this constellation of stuff? Especially because you guys are building on technologies that you can’t really just casually find developers for eg Elixir and Haskell. I keep seeing missing critical features in Realtime and Postgrest, and I know these are armies of 1-2, but it does kind of worry me when I think about investing time and effort into the Supabase ecosystem as a whole seeing more and more launches while there isn’t much action on existing issues.

Example: https://github.com/PostgREST/postgrest/issues/915#issue-comm...

> I keep seeing missing critical features in Postgrest

> Example: https://github.com/PostgREST/postgrest/issues/915

> while there isn’t much action on existing issues.

That one is planned but it's not high priority because it can be solved already with SQL functions[1][2] in a flexible and secure way(GROUP BY is an expensive operation, it cannot be exposed to the frontend just like that).

I do get that some conveniences on the JS libraries are missing but they're not blockers(or critical features IMHO).

[1]: https://postgrest.org/en/stable/api.html#stored-procedures

[2]: https://supabase.com/docs/reference/javascript/rpc

Thanks for the response Steve. There is this “workaround”, but it’s so much more painful in terms of ergonomics we elected just to escape hatch into raw SQL with a different library (Sequelize) in our case. Black boxing some of our business logic into views or RPC is just not something devs I work with are comfortable with. Having business logic live in the db like this just unlocks a whole new world of pain for people who aren’t used to it. Now I have a whole new class of problems too, now I have to have unit tests in the db with pgTAP and now I as a dev have to decide when and where this kind of logic should go in the db vs on the client side and how to test it. In general I would really call this not a viable alternative at all unless there are some comprehensive design documents that say “do this stuff as RPC in the db because it makes sense to do it there, do this stuff on the client”. When I tried selling this ‘workaround’ in its current form to other devs in my org, they all balked at it.

Maybe I’m thinking about how Postgrest is supposed to work fundamentally wrong and all of this stuff is generally supposed to live in the db. But there certainly isn’t any guidance directing that in documentation currently.

It’s weird because I can do everything else the nice way with Postgrest except this. It feels like the part of the codebases where I have to deal with this (and indeed, it comes up every time) is a constant wart in an otherwise pretty good setup.

Thanks for the honest feedback!

There's definitely a lot to improve upon. Not only on features but in documentation as you mention.

I'll revisit this issue after launch week.

Is Supabase targeted towards webdev "apps" or mobile "apps"? As a mobile dev I got excited to check out a Firebase + serverless alternative, but the docs seem very targeted towards webdevs and non-native apps.

I see there's a 1.0 Swift library that's available, would love if someone can chime in with their experience using that in an iOS app.

They seem to have Flutter support but the lack of React Native support is non starter for me.

Actually React Native is supported with the JS libs. While we don't have React Native docs, here is one for Expo which should be easy enough to convert: https://supabase.com/docs/guides/getting-started/tutorials/w...

We also support swift: https://supabase.com/docs/reference/swift/introduction

One more thing - we will have some more announcements for mobile (specifically auth) tomorrow.

I see, awesome. Thanks for the clarification!

I'm working on several RN + Supabase projects and it just works !

There were a few kinks initially, like URL polyfil being missing from RN and the need for AsyncStorage alongside supabase.js but they've all been rectified by the team or made more clear using their Expo instructions in the docs — Although maybe it'd be clearer for people that the expo guide is for RN? People who haven't started using RN might not know the connection?

It's such a pleasant stack, we're experimenting currently with edge functions in place of an API in certain places, so far it's just to use Cloudflare Turnstile to insert contact form records into a database, but it's super trivial.

Excited for the future of edge functions!

Great work!

I've been dabbling with deno for a couple years now, one of the most powerful features I'm excited about is BroadcastChannel[1] support, which works with --unstable in Deno Deploy.

One of the challenges I've run into is debugging timeouts in deno deploy, so I'm curious--

1. is BroadcastChannel supported in supabase self-hosted edge functions? 2. is there more tooling available to supabase edge functions to debug than currently in deno deploy?

[1]: https://deno.com/deploy/docs/runtime-broadcast-channel

--- if curious of specifics, this is my work in progress proof of concept, exploring using pathnames for channels, to get anyone on the same url path connected across regions through sockets and broadcast channel: https://github.com/tylerchilds/kickstart/blob/869506c9dae1e1...

[Supabase engineer & author of the blog post here.]

Thanks! Good Questions

1. We haven't enabled BroadcastChannel in the Edge Runtime. Mainly because we haven't found good use cases for it within Edge Functions (it does make sense as a way to subscribe within a browser client, but not sure how it fits with async/short-lived nature of Edge Functions). Curious about how you plan to use BroadcastChannel in Edge Functions?

2. As I've mentioned in the blog post Edge Runtime allows you to tweak the duration and memory available for an Edge Function (check the examples/main/index.ts in the repo too). Personally, I use this option to debug timeouts and memory issues on Edge Functions. We also plan to introduce better ways to profile your Edge Functions in the future.

Thanks Lakshan!

I don't think my use-case is necessarily a good fit for edge functions. I am trying to achieve what Supabase realtime/multiplayer accomplishes, but generically. I participate informally with the https://braid.org IETF working group, which to over-simplify is CRDTs over HTTP with subscriptions.

I'm interested in web standards and that's what's drawn me to deno, so I'm super excited the more and more I see it being adopted. BroadcastChannel piques my interest because it is perfectly in that gray area of standardization-- it makes total sense on the client and we're on the cusp of discovering what that could look like for servers.

In deno deploy, all the instances of my service are able to be linked together by BroadcastChannel, which I'm viewing as a p2p-style architecture. Ultimately, I'm curious about how this works under the hood and if it would be possible to interoperate a BroadcastChannel between Deno Deploy, Supabase, and say a Raspberry Pi in my house.

I've gone on a bit of a tangent, but I think maybe I should get involved with the WinterCG, since now that I'm putting my thoughts to words-- seems like it fits their charter.

Yep, that sounds interesting. Feel free to share with us if you write a formal proposal. Would love to explore the options to provide better worker-to-worker communication options.

Any details about the removing of Kong? What did you use it for and how will this help with removing it?

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.

This is really exciting Inian. I’ve long felt that api gateways are one of the heavier and more complex parts of the modern infra stack and the work you’re doing to make this more self hostable is laudable!

Congrats on the launch! I’ve been so underwhelmed with Lambda’s lack of forward progress lately and have been wanting to play around a bit with V8 isolates. This looks like a super-easy way to get a runtime spun up and handling requests on AWS.

Open question: what are the benefits of replacing Lambda with this new service, if you’re not using any other Supabase functionalities?

Our Lambdas are currently written in Typescript and built with esbuild. We zip them and push to AWS.

The largest advantage currently (in my opinion) is with respect to cold starts. Lambda has gotten significantly better over the years, but cold starts are still a concern, largely because it’s difficult to anticipate the level of needed provisioned concurrency needed to mitigate it. Not having to think about that at all would be a large advantage (I’m ignoring Lambda SnapStart since it’s strictly limited to Java at this time).

It’s also the case that there’s just so much historical baggage within Node, mainly with regard to CJS. Developing against Deno at least presents the opportunity for us to move past that and improve DX.

These would boot faster since you don’t have to boot a whole OS, just a V8 VM. Downside is compatibility, your lambdas would have to be largely rewritten (especially if they rely on any other AWS services). It’s also probably more expensive since you’d have to keep a EC2 or something up running this.

Kinda wish Amazon would have an alternative runtime that was more like this. They kinda do with lambda@edge, but that’s only for CloudFront stuff, mostly.

Lambda@Edge is a great solution for the locality problem (CloudFront can just route to the nearest edge function, and despite certain headaches, it works well), but what it doesn’t help to solve is the cold start problem. In a sense Lambda@Edge works against it, as provisioned concurrency is only supported for ‘regular’ Lambda functions.

At a certain level of scale, the cost of spinning of an ALB Fargate task (which could run these servers relatively easily) ends up being relatively negligible. Although that’s certainly not true for every org.

Interesting! Do you have an idea of what it would mean performance/latency wise to replace kong with this?

We are yet to complete our Kong replacement. Once we do that, we'll probably publish another blog post with performance benchmarks.

One of the biggest annoyances with Deno deploy/functions is that there is no way to store any data. This would be very useful to e.g. cache an auth token, store a key/value pair, etc. See also: https://github.com/denoland/deploy_feedback/issues/110

Is any work being done to fix this? Or is this out of scope currently?

Yes, this is something we are exploring for Edge Runtime. One cool development is AsyncLocalStorage now works on Deno via a polyfill [0]. We may enable a single node store on Edge Runtime using this. Also, there are some interesting development in Supabase platform to enable Edge Databases, which could also be an answer to this.

[0] https://github.com/denoland/deno/issues/7010#issuecomment-14...

Hey! I wonder, why CEO, not even CTO or other Principal Engineer come here in person. Is it cuz company doing so great that CEO has so much free time to spend it on activity of that sort or HN is consider so serious resource to spend time on it even for C level person..

1. HN has been invaluable to us, guiding what we build and highlighting the areas we need to improve.

2. We encourage all of our developers to participate in the discussions, I just am usually just faster to respond.

3. Personally: I love HN and the community. I read it every day and learn a lot from it. I'm a developer like most other readers