> Not every project needs Postgres, and that’s okay. Sometimes you just want a simple, reliable database that you can spin up quickly and build on, without worrying it’ll hit your wallet like an EC2.

Isn't the operational burden of SQLite the main selling point over Postgres (not one I subscribe to, but that's neither here nor there)? If it's managed, why do I care if it's SQLite or Postgres? If anything, I would expect Postgres to be the friendlier option, since you won't have to worry about eventually discovering that you actually need some feature even if you don't need it at the start of your project. Maybe there are projects that implement SQLite on top of Postgres so you can gradually migrate away from SQLite if you need Postgres features eventually?

Marek here from bunny.net. We’re not saying SQLite is universally better than Postgres. The trade-off we’re optimizing for is cost model and operational simplicity.

Even as a managed service, Postgres DBaaS still tends to push users into capacity planning, instance tiers, and paying for idle headroom. Using a SQLite-compatible engine lets us offer a truly usage-based model with affordable read replication and minimal idle costs.