We're going to start rolling it out for Forks/point-in-time recoveries first, which present less risk to start. Later we'll explore either parallel restores from WAL-E and WAL-G or possibly just flip the switch based on the results.
On restoration there's really no risk to data. Further we page our on call for any issues that happen such as WAL not progressing, or servers not coming online out of restore.
is google cloud storage on the roadmap?
Minio has an interesting feature where it can be a "gateway" to other cloud storage. Google Cloud Storage is one of their specific examples:
https://docs.minio.io/docs/minio-gateway-for-gcs
So WAL-G would talk to Minio, and Minio would transparently proxy that to GCS.
I assume I am switching from WAL-E to WAL-G for more perf. But WAL-E speaks GCS. If WAL-G needs an extra hop to do so, may lose some of the point of it..
That being said, the Minio team seem pretty good with writing performance optimised code. Frank Wessels (on Minio team), has been writing articles about Go assembler and other Go optimisation things recently. eg:
• https://blog.minio.io/accelerating-blake2b-by-4x-using-simd-...
• https://blog.minio.io/golang-internals-part-2-nice-benefits-...
So the performance impact might not be such a problem. :)
Disclosure: I work on Google Cloud (so I'd love to see this tool point at GCS).