I could easily see us adding a simpler

AppendObject

operation to reduce the costs involved since the S3 way requires 4 requests minimum to accomplish this.

I wasn't aware that S3 had something to accomplish this. Never use it. With, Google Cloud Storage if I remember correctly, there's no option to do this. You have to upload a new object and then call a compose to combine the two object.

Gotcha. If you want to find the S3 docs, this is

CreateMultipartUpload

, `UploadPart`/`UploadPartCopy`,

CompleteMultipartUpload

. You start the multipart upload, you copy the original object, and then upload a part for the append. One main difference we have is that R2 has an additional restriction on the part uploading API. S3 requires each part except the last to be at least 5MB. R2 requires each part but the last to be at least 5MB and all parts to be the same size (except for the last part).

For me the use-case for this is related to database operations, where I only want to trigger a database operation or log ingestion when an upload succeeds.

For example, if I upload a file, I would need to run things as a result of that upload (log ingestion, database operation, or other operation involving that file).

whoa, trailing checksums for PutObject. Hoping R2 has something similar https://aws.amazon.com/blogs/aws/new-additional-checksum-algorithms-for-amazon-s3/

When an object is uploaded, I will be updating some KV metadata values and republishing some static web content related to the latest/newest files in an R2 bucket. I'd rather not have to put a worker in front of all read and write requests just to catch the upload events.

when is r2 going to public beta?

Beta's still very competitive (very high demand), probably not too soon but I'd keep an eye on #895794943182909470 #892058508097388544 for updates.

I think you mean #892058508097388544

GA/beta is expected to happen in Q2

most recent estimate was beta in Q2 and GA in H2 (so Q 3 or 4)

h2 being july-december?

nvm, didn't read bracket

Have a little poll about Unicode handling

Is anyone else surprised that other object stores don’t honor Unicode equivalence?

(For key names)

Like if you upload a file on Mac, download it on Windows, then upload it again, you end up with 2 objects instead of 1

(Assuming it has Unicode)

Oh interesting. I didn't know that. That seems, less than ideal

I want to make R2 normalize the keys but it would be a departure from how other object stores work (they force the user to manage Unicode equivalence themselves). My thought is we would treat object keys as unicode equivalence but preserve it when rendering

GCS calls this out and makes the developer have to care (https://cloud.google.com/storage/docs/gsutil/addlhelp/Filenameencodingandinteroperabilityproblems)

message has been deleted

Anyone voting for option 1, I would love to understand your use case/concern. My imagination has failed as to why other object stores have chosen this route

My guess is that they are all following S3, and S3 was kind of sloppy on this when it came out (and then bound by backward compat). In the early days, you could create objects you could not list, or could not delete etc

That’s my hypothesis. I’m wondering if us doing something slightly different will cause issues for users.

It could certainly cause problems if you are doing the S3 fronting right?

Q: Can I store data in bucket WITHOUT versioning. This is a pain point with B2. I want to overwrite a file if it already exists and I don't want to have to track versions.

The default is that buckets don't have versioning & like S3 you'll have to opt into versioning.

The beta release won't initially have versioning support