More and more, developers need to add value to the business, instead of being the key holders of arcane invocations. It used to be that knowing how to use a computer was a technical skills; now it’s evolved into understanding the business.
Also, these tools can't handle certain back end logic (ie, API interactions and integrations, long running processes, etc). Which is the complex bit, anyways.
Otoh, if you aren’t sending 1 request per week to an installation, it’s really not active at all. The overheard of supporting this niche is probably too much for a company that clearly is in ruthless prioritization mode.
Free Tier includes:
compute up to 1 vCPU / 256 MB
storage up to 10 GiB
3 projects per user
Nikita, their CEO, was a guest on the Changelog[0] podcast a month or so ago. Well worth a listen, great episode.
https://community.neon.tech/t/plans-for-logical-replication/...
I'm also really excited about Neon.
My dream stack is Neon (Postgres) + ReadySet (database caching proxy) + Supabase.
Personally I'm more interested in vanilla PostgREST than Supabase's implementation of it, or their realtime implementation. It seems really cool but I'm not 100% sold on their ability to evaluate complex RLS rules, which is an important one for me.
ReadySet looks cool, I'll check it out. Thanks!
I haven't used their role based stuff but it looks pretty good.
You don’t need to be sold on our ability - all rules are run on the database itself. Supabase is just Postgres, we don’t run any forks. We run vanilla PostgREST too (behind a proxy)
I've had another brief look at that repo, and either you've clarified a few things since I last looked at it, or I didn't look at it closely enough in the first place. It makes far more sense to me now, the impersonation + re-query mechanism puts me at 100%.
Thanks for the response, I appreciate it.
[1] https://fly.io/docs/postgres/getting-started/what-you-should...
Could do other things like directus (handles the api gen), planetscale has free mysql tier or even using airtable as the db, it provides the api part.
I find Eloquent's approach to disconnect models from migrations a bit dangerous, but it could be me as I don't have much experience with Laravel. PlanetScale/Vitess doesn't support foreign keys, which is nice for distributed (planet scale, ha!) apps, but could be a problem for certain types of applications. I'd rather stick with (stock-ish) PostgreSQL.