4 ms·

That's pretty incredible. With no price increase either. Using s3 as a makeshift database is possible in a lot more scenarios now. I especially like using s3 a

That's pretty incredible. With no price increase either. Using s3 as a makeshift database is possible in a lot more scenarios now. I especially like using s3 as a db when dealing with ETLs, where the state of some data is stored in its key prefix. This means that the etl can stop / resume at any point with a single source of truth as the database. The potential drawback is cost of course; moving (renaming) is free but copying is not. S3's biggest price pain is always its PUTs. In many ETLs this is usually a non-issue because you have to do those PUTs regardless, as you probably want the data to be saved at the various stages for future debugging and recovery.

foxhop 6y ago
Yup me too! Checkout this state_doc Interface I wrote in Python for building a state machine where the state is stored in S3. I never bothered to solve for the edge case of inconsistent reads because my little state machine only ever measured in hours when it slept waiting for work and then minutes in-between waking up and doing work to verify restores. With the news of S3's strong consistency my program is immediately safer to use for some set of defects, since the underlying datastore properties, S3 has made my codes naive/invalid assumptions, true. https://github.com/remind101/dbsnap/blob/master/dbsnap_verify/README.rst#state_doc https://github.com/remind101/dbsnap/blob/master/dbsnap_verif... I should likely pull out the StateDoc class into it's own module.