We deal with payloads that are just a little too big for a database (we run Postgres and Clickhouse) but just too frequent (~100 per second) and small (think largish json blobs) to be effective on S3.
We are write heavy. Reads are probably 1% but need to be instant for a good UI and API experience.
What I have seen done before is concatenating many small blobs into a single large blob that is stored on S3. This works great for batch processing afterwards.
If you need read access to the objects one option is merge them into a large blob, and then create a small index file that keeps offsets for each of the tiny blobs. Then you fetch the index file, find the offset of the tiny blob you want and, do a range request for this offset into large blob.
This mostly works when you're not read heavy. I recently did an index file for serving HTML files out of a tarball. As an alternative to uploading many small files.
> We are write heavy. Reads are probably 1% but need to be instant for a good UI and API experience.
It sounds like the recently released OVH High Performance Object Storage[1] might be a good fit.
It has better performance than S3[2], completely free API calls, and $0.015 / GB egress.
[1] https://corporate.ovhcloud.com/en/newsroom/news/high-perform...
[2] https://blog.ovhcloud.com/what-is-the-real-performance-of-th...
Minio: https://github.com/minio/minio
SeaweedFS: https://github.com/chrislusf/seaweedfs
Ceph: https://ceph.com/en/discover/technology/that ignores the reality that RDS storage is comparatively expensive.