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.
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.
> 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).
Thanks for the response Steve. In general, I unfortunately don’t agree that this is a “convenience” feature or that this alternative you brought up is “flexible”.
This way of doing things is just so much more painful in terms of ergonomics we elected to instead 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 in the application layer 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 in the application layer”. 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. And in general I think if you want to advocate for a design where you split business logic between your application layer and your db there should be a plethora of examples where this has been done successfully, especially because that idea goes very much against how a typical developer thinks about system design.
It’s weird because I can do everything else in a “typical CRUD app” 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.
Please don’t take this as me hating on Postgrest. I think it’s absolutely fabulous software and I am in genuine awe of what you have achieved. I can only aspire to have your work ethic and vision when it comes to this kind of stuff. I just want to help you see how myself and the devs I work with use it in real life and how they react to Postgrest in the context of using it when trying to make maintained business applications over years of time.
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.
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
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.