http://aws.amazon.com/simpledb/ With all the other options available, I'd like to hear some stories. What types of things is it good for? Why not just MySQL?
No service outages yet, but response time rarely drops below 50ms (from an EC2 instance) and there is a serious long tail on queries. I have seen 10 minute windows in which the fastest response time was 500ms. That is amazingly slow.
I've used it in the past for a logging tool that we wrote for our production app servers. I was super unimpressed with it. Bindings (for ruby) at the time really sucked, and were not clear which ones to use.
Also, SLOW. HTTP WAN db access is what you expect it to be.
Lastly, I don't like their data storage format at all, arrays of arrays, is painful and requires a lot of hoop jumping at times.
We switched to a local mongodb server as a near drop-in replacement, and it was a billion time faster and more efficient.
The final nail in the coffin was the data storage per record limitation, I think it was 1MB or something, so it was easy to piss off when capturing stack traces, hardly better than syslog at that point.
So it's slow and needs memcached or something? That's dissapointing. What usecases would you use it for?
Never going down just doesn't seem that big of a deal for me, their aws mysql service also "never" goes down, so I might as well use that and gain all the sql advantages, right?
Never going down in a database doesn't just mean that it doesn't have downtime, it also means that as a whole system it's immune to bad queries.
Bad queries can destroy you in MySQL, if you are doing dynamically created queries that hit un-optimized areas, it can bring down all the other queries too.
I'd typically use Memcache with MySQL too, so there isn't any real difference in that case.
One use case I like SimpleDb for is for small scripts that need a very simple data store.
It depends on what you think "slow" means. It's the same speed when you're running one concurrent query as it is when you're running a hundred million concurrent queries.
We use SimpleDB from outside of AWS datacenters (Rackspace), and it does go down every now and then. Usually once a week for a couple of minutes we get timeouts and connection resets.
For us it was a good choice because we were on tight schedule, and didn't have to spend time on operation. In the longer term however, we'll migrate back to an in-house solution.
Never goes down or causes operational headaches is something I've found SQLite excels at, plus you get all the benefit from a query-optimizing relational database, plus a hot backup is just cp the database file.
We use it as a subscription table for a constantly running process that pulls reports from search engine APIs (paid search data from google, for example).
Each SimpleDB Item represents an account for which we want search engine reports. The Item contains all the pieces necessary to tailor the API request for a specific account. When we need data for new accounts we just add them as new Items to SimpleDB, and the reports are picked up in the next run.
Cheap, available to any EC2 instance, and we never have to worry about DB maintenance or failures.
We're using it for our multiplayer platform (http://flockengine.com) to store user accounts and attributes.
Advantages: Easy to use and no need to maintain a custom database infrastructure, high availability, no SQL injections, great Python library (boto)
Downsides: Slow requests, not exactly cheap, lots of limits on entries(1), need to carefully handle numerical data for sorting(2), horrible PHP library
We tried using SimpleDB initially for a startup. We store a lot of numerical data. When it came time to actually query this data and do anything meaningful with it we ran into a lot of issues because all values are stored as untyped strings (comparison and ordering is always lexicographic). There are ways around this using zero-padding, but they are ugly and difficult. The SimpleDB query language is also limiting if you are accustomed to SQL and relational data structures. In the end it just wasn't the right fit and we reverted to an RDBMS.
I have used it, but not much. It is fast enough when client apps are running on an EC2 instance, but for some reason it is extremely slow for remote access (more than what I would expect from remote network access). As a result, it is a nuisance for development using my laptop.
I tried a Python SimpleDB simulator (for development) a year ago, but did not have much joy with it. For Ruby, there is a gem that wraps CouchDB and SimpleDB with (mostly) the same API.
As some have mentioned here, there is a latency cost for every request, maybe around 200ms. So, we try to pack as much into each request as possible.
QuickFuse is a voice app development environment. Since customers are using QuickFuse's Simple Database to store completely arbitrary, semi-table-structured data, SimpleDB was really one of the few choices we had for allowing this data storage to scale on the backend. One of our main requirements was that customers wouldn't need to specify the structure of their tables in advance, so most other databases weren't an option, except maybe Couch.
What's perhaps more interesting, for anybody who's tried out QuickFuse, is that we wrap everything in both a nice GUI so people can upload "tables" of data and work with them, and also an API so data can be uploaded and downloaded programatically. Both the API and GUI make calls through our servers to SimpleDB.
Also, when they mention "high availability", does that mean it's fast? Or that it doesn't go down? They do mention that from ec2 instances, the speed is "near-LAN", whatever that means in practice.
http://github.com/crawshaw/saws
No service outages yet, but response time rarely drops below 50ms (from an EC2 instance) and there is a serious long tail on queries. I have seen 10 minute windows in which the fastest response time was 500ms. That is amazingly slow.