You are right about the activation energy to throw up anything new really comes down to a hosted db that won't rot. My initial experience with supabase was incredible in that sense: any client-side framework I wanted, deployed statically while still integrating with full Postgres, for free!

Problem is supabase rots. And turning that project into anything meaningful is basically undoing everything you got for free up front.

My solution today is sqlite. I'm not diehard typescript so it turns out traditional backend apps like rails running sqlite on tiny/free hardwire is pretty nice.

That said, client-side runtime will always be alluring because it can be deployed statically. So you've got something there that I'll check out.

▲

trestacos 21 minutes ago | parent [-]

As someone looking to use supabase for a project, I'd love to learn more about what you mean by supabase rots - did you run into scaling problems?

	▲	apsurd 3 minutes ago \| parent [-]
		For me, not scaling, the opposite of scaling. For the scaling side there's two much more involved posts about the topic: https://news.ycombinator.com/item?id=36004925, https://news.ycombinator.com/item?id=48038827 For toy apps and initial prototypes the problem is they aren't going to get used so the rot is that they will be in a good-enough state to come back to when you get the time. With supabase the drop-in auth completely broke at some point, probably just a deprecation I didn't keep up with. The postgres instance spins down when you aren't using it, which is understandable and I will say it works, it's just Postgres and you get the database dump if you need to move or come back a year later. The nuance here is that you get the raw connection string + the postgREST API which all makes sense but you're choosing full cloud/client mode which is completely different from if you just went with the raw connection string behind a server layer. I kinda had to work through all of that learning on my own. The full client mode trade-off is that you'll be doing everything with that pattern, handling migrations, security, auth, it's just kinda... it's a whole thing, when as a professional dev, I would have just chosen the raw connection string and managed the database from the server until I outgrew it and I'd have the dev workflow already, it's just a Postgres db. Or sqlite to start, same reasoning it's all the same dev workflow, the problem is the cloud-hosting transition, which is why fully-managed cloud db accessible from an edge/client runtime is so alluring, but you're trading two very different ergonomics. I'm thought-dumping, gotta run, hope this helps.