One thing that just seems inevitable is that they will be bought, and I wonder if (how?) things will change when they do...
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
* 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).
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.
I see about 10 classes there. Isn't that awesome? 10 simple classes - thats it. To make it more concrete - have a look at PFObject. This simple class seems to be a wrapper around NSDictionary but it gives you CRUD commands and it is using setObjectForKey: and objectForKey:. If I show this class to one of my Objective-C students they will immediately know how to use it.
Parse really knows how to make complex things easy going. I will evaluate Parse with a real app soon but I am very confident that it will be a good experience.
Could you turn off the CSS for changing the highlight color? I know it is all the rage these days, but it is an accessibility issue for me (and probably others as well). I use highlighting to make it easier for me to read text (it helps by eyes track better). When you change the color (especially to something garish) it substantially reduces the usability of the site for me. Yes it is just one Firebug edit away, but really I shouldn't have to do it.
Operating systems allow people to set custom highlight colors for a reason. I don't see why website authors think they know better than their users.
I remember a frontpage 97 feature that scanned your site for broken pages. Seems like we need a web 2.0 version of that (because I've noticed a new/small sites with dead links recently that should have been [automatically] caught).
Kind of sorry to see the $49/month plan go. The jump from free to $199 seems a little steep. (I know there is pay as you go for the basic level, but I'd kind of like to know the costs before hand)
All in all I like the new pricing.
Congrats for the release.
We do track queries and accesses to create appropriate indexes on the fly. Whenever we used databases in the past, indexes always seemed like something that should be done intelligently out of the box, so we decided to make Parse work that way.
Having seen how easy it is to look at the plain traffic a mobile app sends with http://mitmproxy.org/ I would have concerns to use this.
Or is there some per user authentication?
I would say that you shouldn't really worry about 'sniffing' traffic, because whatever countermeasures you take chances are if someone cares enough they'll work around it.
Parse has an access-control model for objects: objects can have read/write permissions for users, groups, or everyone. For example, you might have an object in Parse representing a comment, which the owner could edit and everyone else read.
Obviously the Parse API itself is rather public, and it wouldn't take a huge amount of skill to extract your client keys from an Android / iOS app: but as long as you've designed your ACL (access control list) correctly, it won't matter as your user will have to be logged in and authenticated to access sensitive objects.
But it's possible to edit the ACL from a client. Isn't that a potential weakness?
See this question: http://stackoverflow.com/questions/2135081/does-my-applicati...
If you have more specific questions about how to use this for an app, feel free to drop us a line at feedback at parse.com.