They don't have the full suite of GCS's capabilities (https://cloud.google.com/storage/docs/request-preconditions#...) but it's something.
My approach on S3 would be to ensure to modify the ETag of an object whenever other transactions looking at it must be blocked. This makes it easier to use conditional reads (https://docs.aws.amazon.com/AmazonS3/latest/userguide/condit...) on COPY or GET operations.
For write, I would use PUT on a temporary staging area and then conditional COPY + DELETE afterward. This is certainly slower than GCS, but I think it should work.
Locking without modifying the object is the part that needs some optimization though.
* https://rockset.com/blog/separate-compute-storage-rocksdb/
* https://github.com/rockset/rocksdb-cloud
Keep in mind Rockset is definitely a bit biased towards vector search use cases.BTW, the comparison was only to give an idea about isolation levels, it wasn't meant to be a feature-to-feature comparison.
Perhaps I didn't make it prominent enough, but at some point I say that many SQL databases have key-value stores at their core, and implement a SQL layer on top (e.g. https://www.cockroachlabs.com/docs/v22.1/architecture/overvi...).
Basically SQL can be a feature added later to a solid KV store as a base.
However it will be much simpler with the new conditional writes