Building backends is easy. It is sort of weird. In 2003 no one would bat an eyelid at building an entire app and chucking it on a server. I guess front-end complexity had made that a specialism so with all that dev energy drained they have no time for the backend. The backend is substantial easier though!

These high value startups timed well to capture the vibe coding (was known as builidng an MVP before), front end culture and sheer volume of internet use and developers.

It’s harder than signing up for Firebase.

You have to understand a separate set of concerns. Spin something up on ec2, hook it into a db, configure https , figure out why it went down, etc.

You’re right though, once I build a complex front end I want someone else to do the backend.

You need all that stuff when you need to scale. For an MVP you can get away with very little.

It depends on how you deploy it.

Django on Render( and presumably a heroku) just works.

It's still much more work that just dropping in a Firebase url. Firebase can lead to poor design choices and come back to bite you, but hopefully by then you've already raised a few VC rounds and you're rolling in dough.

"Easy to provision" is mostly a strategic feature for acquiring new users/customers. The more difficult parts of building a database platform are reliability and performance, and it can take a long time to establish a reputation for having these qualities. There's a reason why most large enterprises stick to the hyperscalers for their mission-critical workloads.

That reason also includes SOC2, FedRAMP, data at rest jurisdiction, availability zones etc. And if large enough you can negotiate the standard pricing.

For sure. And oftentimes these less sexy features or certifications are much more cumbersome to implement/acquire than the flashy stuff these startups lead with

Supabase is particularly valuable for its users. Or right now “vibecoders”

> Maybe a NoSql DB that “understands” the Postgres API?

I believe there are several of these already, like Cockroach DB.

> Someone at AWS probably thought about this, easy to provision serverless Postgres, and they just didn’t build it.

AWS is working on this as well: https://aws.amazon.com/blogs/database/introducing-amazon-aur...

DSQL is genuinely serverless (much more so than "Aurora Serverless"), but it's a very long way from vanilla Postgres. Think of it more like a SQL version of DynamoDB.

Supabase is not just a hosted Postgres, it’s a full(ish) backend stack built on open source components comparable with something like firebase. But being Postgres, encourages same data modeling (and an escape hatch). Their type generation and SDK is quite good, too. It’s one of my favorite services and powers to projects of mine, soon to be 3.

*encourages sane modeling. I can’t type today.

I've tried Superbase.

Their choice of Deno for edge functions is... Well, unique.

For my current project I have to do a lot of quirky logic, and I kept hitting a brick wall with Supabase.

I also didn't enjoy the self hosting journey. Not exactly easy.

Haven't used their edge functions yet. What's the issue with Deno (I'm not familier with it)?

For the other stuff, what do you find quirky?

Firebase let's you write functions in normal node js and Python.

Supabase only supports Deno. The quirkiness is my own server side logic. Tbf, I've tried to build this project at least 4 times and I might need to take a step back.

You aren’t forced to use their serverless runtime - you can pull their js lib into anything and sent events in several ways. There’s even Python libs.