There are a few. Mongo has excellent integration with Hadoop and is becoming very popular in the big data analytics space. Likewise it is gaining traction in the EDW space as a result of their partnerships.
Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.
> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.
It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'.
In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have your database broken into (if it can even be called that, without authentication), or you end up corrupting your data because two of your applications disagree over what the current object schema is.
To know how easy something really is, you need to compare how hard it is to set something up correctly. And once you do that, MongoDB falls far behind.
I'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.)
Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.
Realistically, though, almost always at least some portion of your hacks makes it into production. And if you're saving 10 minutes for 5 hours lost, then even at a going-into-production-rate of 10%, it's still not worth it.
Hacks that remain hacks in 100% of the cases, are rare :)
I've always thought it would be a great idea to create an explicit "prototyping database" that has limitations that actually prevent you from putting it in production, no matter how small your use-case. Things like "erases random rows after 24 hours" or "default row limit of 100; can increment this by 100 once per day by solving a CAPTCHA."
Why would I care about having my database broken into or even my data being corrupted for hacks/spikes. The very definition of these is that they are throwaway designed to test an idea before rebuilding in something more suitable.
And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared library. I can just as easily corrupt PostgreSQL if I change data types without updating the ORM.
> Why would I care about having my database broken into or even my data being corrupted for hacks/spikes. The very definition of these is that they are throwaway designed to test an idea before rebuilding in something more suitable.
> And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared library.
This doesn't work if there is no shared library, for example if you have two separate components in different languages both using the database. And at that point you're (poorly) reinventing a schemaful database anyway.
> I can just as easily corrupt PostgreSQL if I change data types without updating the ORM.
A good ORM will abide by your database schema - and no, you can't "corrupt PostgreSQl" by "not updating your ORM". It will, at most, error out because you're trying to work with non-existent columns.
In a schemaless database, there's no such thing as "non-existent columns", thus you can quietly corrupt data without realizing it.
Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.