Alright, I can give you a better example. Netflix uses S3 to store movies that haven't been rendered yet. It's definitely a database. The server says "I need to render this movie to the iPhone format, what are the movie bits" and the "database" (S3) returns the entire movie.
Also, I would argue that static content delivery is just another form of database. It's just a massive key/value store, there the keys are the files and the values are the contents of the keys.
Let me ask you this: What is your definition of a database?
Yeah, right, the definition of the database is fuzzy. As every technology, S3 has its pros and cons, and the latency is a con this time. Take a latency-intensive application (1), and it will feel miserably slow with S3. Take a storage-intensive application with not-so-frequent access requirement (2), and it will be just OK with it.
(1) any page-load that requires 3-5 sequential DB access (based on the results that are returned in the previous steps).
(2) Netflix's "let's store somewhere until we really want to use it" qualifies.
I don't think I could come up with a coherent definition of a database which includes low-durability NoSQL key/value stores yet excludes file systems. This doesn't necessarily mean that file systems are a database, however; it could be that in order for the word "database" to be meaningful it must be defined in a way that excludes some things commonly thought of as databases, similar to why Pluto was deplaneted.
Also, I would argue that static content delivery is just another form of database. It's just a massive key/value store, there the keys are the files and the values are the contents of the keys.
Let me ask you this: What is your definition of a database?