If you forget about the iOS SDK for a minute, Parse is essentially a modern CouchDB.
Couch got a lot of things right, and with the advent of client-side apps I'm guessing the idea of database-as-API makes a ton more sense to people now than it did five years ago.
But because CouchDB wasn't made with modern web app development in mind, it has these awkward almost-right-but-not-quite features, like the way it handles push notifications (see http://guide.couchdb.org/draft/notifications.html), design documents, couch apps, map/reduce and so on. All of that stuff is great, but none of it works quite as smoothly as it should.
Anyway, I would love a database with these features:
* RESTful, with basic filtering operations built-in
* schemaless
* uses webhooks to provide push notifications, plugins (e.g. ACL, validation) and map-reduce -- meaning you can "program" your database using any language you want, couple events to background jobs etc.
* websocket support
* multiple engines so you can back a collection with Mongo, Redis, Neo4j, S3 (store/serve media) or anything else depending on your requirements, but still have all collections exposed to the web as JSON with a uniform querying interface
* smart view caching
The trouble with Couch is that you're supposed to be able to build apps that are backed with just your database and nothing else, but it never ends up being quite flexible enough to do exactly that.
But a database that would allow you to replace your entire back-end framework with just a couple of independent snippets of code to handle validation, authorization, sending email and what-not but with all the CRUD you need for an API-driven app out of the box... hells yeah.
We don't meet all your bullet points from above, but your closing paragraph sums up what we're doing with Trestle pretty well (i.e. more than just a web connected database).
While I like the simplicity that Parse promises, I do worry a little about having my users' data being potentially held hostage by a 3rd party..
what if I publish a wildly successful app and store all my users's data using Parse, and then one day they decide to triple their prices? Or maybe sell their business to Google who decides to shut down the service?
We don't want to hold your data hostage. We're convinced the right strategy is to make it easy to migrate off Parse, so that people won't be concerned when moving onto Parse. For example, we recently launched one-click export, so you can get out all the data your app is storing on Parse without writing any code.
As stdbrouw mentions it's basically a CouchDB, I thought about using it in my own server.
However I prefer to use Parse to handle all that without me actually caring about the server side issues and specially given that the price is quite cheap for what my apps need.
Another advantage is their SDK that simplifies communication with the backend even further.
One thing that I don't like is that they don't have a way to add Server Side logic (as Cloudmine does) so my current solution is having a separate heroku instance for those cases.
