I have nightly backups dumped to Cloudflare R2 from a GitHub action.

If Neon announces they're shutting down, migrating the database to another provider is a bash 1 liner and an hour of downtime.

If Neon just "goes dark" I can recover from the nightly backup and lose at most 24 hours of data - data that is denormalized into other systems and can be manually recovered if absolutely necessary (but probably not).

Not every company is the same, but for many use cases the database layer is an inconsequential decision as long as the API is fungible for your use case.

Not every decision is a 1-way door.

The most important way you can spend your time when making a 1-way door decision for a company isn't picking the right door. It's turning the decision into a 2-way door.

I‘d argue that the most important way to spend the time is on building something customers want and not micro-optimize with shiny database vendor of the week. Get a boring managed Postgres and it‘ll scale for a very very long time, it‘s well understood and if you hit the limit, that‘s a good problem to have and there‘s many solutions for that when the time comes.

My customer profile at the time was mom-and-pop small businesses. Bespoke application development that automated back office work delivered on ~6week timeline.

The size of their tech department was 0.

The goal with the architecture I delivered was to delegate as much as possible below a vendor boundary.

My solution was: Cloudflare workers for compute. R2 for storage. Neon for database. HTML/JS/CSS for the frontend.

Neon wasn’t a micro-optimization. It was the only vendor in town that would own that much of the DB layer’s responsibility (D2 wasn’t prod ready yet).

12months in and so far so good. I’ve had to “come back in” for a total of 30minutes of maintenance when mobile Chrome broke uploading a photo via camera.

Wouldn‘t you want the most boring solution that‘s unlikely to change in the next 5 years for this use case? (AWS etc.)

With a company that did a big funding round it‘s very likely that it gets acquired, shut-down, products get sunsetted, API endpoints need to be changed in the next years.

    #!/usr/bin/env bash
    OBJECT_NAME="pg_dump_$(date -u +"%Y-%m-%dT%H:%M:%SZ").dump.gz"
    pg_dump --dbname="${DB_CONNECTION}" | gzip > "${OBJECT_NAME}"
    rclone copy "./${OBJECT_NAME}" "cf:${CLOUDFLARE_NAMESPACE_ID}/db/"