actually the new default is sane. its WAY WAY WAY WAY better than before. especially for multi uploads. it's basically one of the features where gcloud had a insane edge. another thing was If-Match in cloud storage.
AWS S3 SDK breaks its compatible services
41–50 of 91 posts
Re: AWS S3 SDK breaks its compatible services
#42I wish more services would become de-facto standards and there were many implementations of the same API. I'd love more (cheaper) DynamoDB compatible APIs.
Why would anyone want a DynamoDB compatible API?
Re: AWS S3 SDK breaks its compatible services
#43I wish more services would become de-facto standards and there were many implementations of the same API. I'd love more (cheaper) DynamoDB compatible APIs.
Why would anyone want a DynamoDB compatible API?
Dynamodb is great. A ton of services, including this site could literally be implemented with dynamodb alone.
Re: AWS S3 SDK breaks its compatible services
#44[deleted]
Re: AWS S3 SDK breaks its compatible services
#45This bit us pretty hard at Tigris, but we had a fix out pretty quickly. I set up some automation with some popular programming languages so that we can be aware of the next time something like this happens. It also bit me in my homelab until I patched Minio: https://xeiaso.net/notes/2025/update-minio/
Re: AWS S3 SDK breaks its compatible services
#46> the AWS team has implemented it poorly by enforcing it This is whiny and just wrong. Best behavior by default is always the right choice for an SDK. Libraries/tools/clients/SDKs break backwards compatibility all the time. That's exactly what semver version pinning is for, and that's a fundamental feature of every dependency management system. AWS handled this exactly right IMO. Change was introduced in Python SDK v…
You mention semver, yet you also show that this API breaking change was introduced in a minor version.
Not entirely sure that's how things work?
Re: AWS S3 SDK breaks its compatible services
#47Time for the community to support a standards body effort to define S3 compatibility under its own brand and standard.
Having a way for vendors to publish some Level of compatibility would be a great help. Eg Tier 1 might mean basic upload/download, Tier 2 might support storage classes and lifecycle policies etc. Right now is just a confusing mess of self-attestation.
Re: AWS S3 SDK breaks its compatible services
#48Earlier quoted context omitted.
Why would anyone want a DynamoDB compatible API?
Dynamodb is great. A ton of services, including this site could literally be implemented with dynamodb alone.
As always, "it depends", but I'd argue DynamoDB has too many constraints and weird limitations: indexes, query language, item (row) sizes. Unless you really know what you're doing I would not suggest it. You'll likely paint yourself into a corner.
Re: AWS S3 SDK breaks its compatible services
#49> the AWS team has implemented it poorly by enforcing it This is whiny and just wrong. Best behavior by default is always the right choice for an SDK. Libraries/tools/clients/SDKs break backwards compatibility all the time. That's exactly what semver version pinning is for, and that's a fundamental feature of every dependency management system. AWS handled this exactly right IMO. Change was introduced in Python SDK v…
I want to see the author using GCP. That's where you get actual compatibility breakages.
Re: AWS S3 SDK breaks its compatible services
#50Earlier quoted context omitted.
Dynamodb is great. A ton of services, including this site could literally be implemented with dynamodb alone.
As always, "it depends", but I'd argue DynamoDB has too many constraints and weird limitations: indexes, query language, item (row) sizes. Unless you really know what you're doing I would not suggest it. You'll likely paint yourself into a corner.
In practice most of the constraints are pretty sensible though. You just need to think a bit about your query patterns.
It’s certainly not for all use cases, though.