Argh. I wish I could upvote this twice.
One of the main reasons we never used google spanner was that we can’t test it locally.
One of the main reasons we never used google spanner was that we can’t test it locally.
Every startup I've worked at (and I've been at this for 15+ years) has moved hosting providers, but I still wouldn't put it high on the list of reasons to avoid vendor lock-in. If you make sure someone(s) know how the app actually runs, and you try to pick stuff you can run locally, the vendor lock-in stuff won't be your biggest challenge in the move.
I hate to tell you this, but there was a thread on HN about this exact topic not too long ago. While becoming less common with AWS, Heroku, Cloud Run etc, there are still companies large and small, that get it working on their machine then just run it off their machine until it breaks.
In fact, one of my favorite stories is a guy I know who does ML work gets a crazy multi CPU, multi GPU workstation for each project, and, when the project is running on his machine, they slap readyrails on it and ship it to the data center to run in prod.
looks like google spanner have plugged that workflow gap since you evaluated it for your project:
> The Cloud SDK provides a local, in-memory emulator, which you can use to develop and test your applications for free without creating a GCP Project or a billing account. As the emulator stores data only in memory, all state, including data, schema, and configs, is lost on restart. The emulator offers the same APIs as the Cloud Spanner production service and is intended for local development and testing, not for production deployments.
https://cloud.google.com/spanner/docs/emulator
although there are https://cloud.google.com/spanner/docs/emulator#limitations_a...