First, S3 and a SQL database aren't comparable. But I think you're bringing up S3 because they're using Litestream to ship WAL frames to S3. Go read the Litestream documentation; Litestream syncs to basically anything. They don't need to "migrate to another S3 compatible backend"; they can migrate to almost anything that can save a file.

It's a super confusing argument regardless, because the industry is lousy with "S3-compatible backends".

> migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted mysql or postgres

You may be right. I have no experience migrating litestream but from the docs (https://litestream.io/guides/) it is literally cp'ing files from S3 to wherever and exec'ing one of these one-liners (of course, the devil is in the details):

   litestream restore -o my.db s3://BUCKETNAME/PATHNAME
   litestream restore -o my.db abs://STORAGEACCOUNT@CONTAINERNAME/PATH
   litestream restore -o my.db gcs://BUCKET/PATH
   litestream restore -o my.db s3://SPACENAME.nyc3.digitaloceanspaces.com/db
   litestream restore -o my.db s3://BUCKETNAME.us-east-1.linodeobjects.com/db
   litestream restore -o my.db sftp://USER:PASSWORD@HOST:PORT/PATH

Litestream author here. Yeah, you're basically right but it's simpler than a DB migration. No need to copy the old data over. You can remove the `-litestream` metadata directory and point it at a new replication destination and it'll automatically re-snapshot the database begin replication.