No joins - SimpleDB was designed for parallel operations - so if you need data from multiple tables, you need to fire multiple queries (in parallel preferably).
No retrieval of multiple attributes - You cannot retrieve attributes from multiple items. So if you need to retrieve 10 items, you'll have to first fire the condition query to get the item-ids and then 10 queries for each item. If you're using serial access, this could be painful.
UTF-8 issues with the REST interface - Minor annoyance. It works with the SOAP interface though.
1024 byte limit for each attribute - This could sometimes be an problem, especially if you're using UTF-8 data (with the REST interface issue)
If you're ready to code for parallel access, no UTF-8 (while using REST), and don't mind the 1024 byte limit then you could give it a try.
Could even run the engine on EC2.
Providing some kind of higher level abstraction in a pay-as-you-go utilisation, hosted on ec2 and maybe backed on to simpledb.
You'd really want to throw memcache in there as well. I wonder how easy porting that to memcache and simpledb would be?
i would love to pay for process hours on some software. i wish there was standard way for aws customers to exchange services based on process time.
in all likelihood amazon has done some of this work for simpleDB, but it would be great to build a piece of code on one linux box and then to sell that time to other users.
i could think of a number of situations where I would love to pay for process time instead of instance time. email, databases, caches, load balancing, etc...
i am a paying customer of s3 and ec2. are you suggesting i should have a simpleDB account?