Mongo Database

A NoSql database, http://www.mongodb.org/ , with a _long_ list of customers, and only primal database abilities:

JSON (JavaScriptObjectNotation) based documents
A server with CRUD & ACID
the ability to store arbitrary dictionaries as data buckets, in flat collections, in databases.
blazing fast indices
replication & clustering
unique record IDs

That's all. To get schemas, relations, & migrations, you write them yourself into your ORM layer. OR you encode them as embedded application-specific JavaScript that Mongo stores & calls at various trigger times.

Transactions in MongoDB are limited to a single document, though one can apply all the normal tricks involved with ReadCopyUpdate and PersistentDataStructure to explicitly model larger transactions. Similarly, we can model 'pending transactions' explicitly as document state, assuming sufficient cooperation between applications.

This is a lot of extra complexity for the application and schema developers to deal with, but I guess the hope is that it isn't often necessary.

After I switched to MongoDB, I was surprised how little SQL I missed. It seems that adding whatever touch of relations you need, to your ORM, is actually cheaper than adding all the excess cruft you need to connect a modern language to classical SQL statements. --PhlIp

What sort of application are you developing?

A ThinServer? that pushes dynamic content to iPads, and journals which iPads have what version of what content.

These are not us, but we are in this space:

http://www.macrumors.com/2011/08/23/united-airlines-deploying-11000-ipads-to-pilots-as-electronic-flight-bags/

http://www.tampabay.com/sports/football/bucs/article1187879.ece

Fat server (the WorldWideWeb) was fun, but we are on to the next big thing. And we don't use Mongo for the actual relations, not because they are too few, but because they are too many!

As a fellow application developer, I'm not surprised at how little SQL you missed. Or, how little you missed SQL. You will miss SQL, however, when management decides your storage solution (which is what NoSql databases are) needs to be concurrently shared by multiple applications -- some legacy, and some new, in a variety of languages and platforms -- and support ad-hoc queries from popular reporting and/or ETL tools.

Ah, the "older, wiser, and more experienced than you" argument. I'm sure NoSql can be abused, but point of our server is stash everything in a common database cluster, and serve it all via REST to multiple applications. So, yes, we have the ad-hoc query layer...

No, that would be the "been there, done that, got the T-shirt" argument. What you have is a general access mechanism using a recognised architectural style. You have neither a standard query language nor a standardised protocol, either of which could be the basis for an ad-hoc query layer. As described, there's nothing "ad-hoc" about it.