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.