I really don't understand this no-sql everywhere trend.
Types and structure definitions ARE useful. There are times when you may find them cumbersome, but most of time they're not (especially when working in teams).
The more i think about it, the more i think my ideal stack would be this :
Postrgesql with no-sql extensions ( for when you may need flexibility), typed python or typescript or dart( or any language with optionnal typing) on the server, and typescripted js lib on the frontend
I'd call it the Optional Typing Stack ( but ots isn't nearly as good as "mean" i must say).
Structures are useful - I'm actually a lot more comfortable putting things in MongoDB when I know they're coming from a strongly typed language than if they're coming from Javascript, because that way I know they've gone through a rigid "schema" at some point. But I don't think SQL's very limited datatypes are the best way to express the constraints on a typical business object. What I'd really like is a database that stored object instances, in a language that made a type-level distinction between serializable/value objects and non-serializable objects (one of those projects I keep meaning to do is the design of such a language). ZODB tried to do this in python, but it'd be far more useful in something strongly typed - I've heard Google have had some success with storing protobuf objects directly in a database? The protobuf schema is rigid enough to provide the kind of guarantees you get with SQL, but a lot easier to map domain objects onto.
Which really sums up the advantage of MongoDB to me - JSON is a more natural fit for domain objects than SQL tables.
They're very limited compared to what you'd get in a real programming language. The fact that the language needs to define types for so many things is actually a demonstration of this - the reason postgres has built-in types for things like IP addresses or line segments is because it's too hard for users to implement such things themselves and very little notion of library code.
Again, you haven't used Postgres very much if you think that. IP addresses are in there because they are generally useful, not because they're hard to implement.
Go have a look at the complex number implementation here: http://www.postgresql.org/docs/9.1/static/xtypes.html then come back and tell me that Postgres is "not a real programming language" (whatever that means these days).
With MongoDB/Mongoose there absolutely are types and structures. Schemas have structure and types for their fields, all of which can be enforced, validated and brought together for non-trivial querying. Just because its DO/NoSQL doesn't mean there's no structure.
Umm .., no .. if you have a large number of tables and need ACID compliance, I've found ORMs to be horrid. They hide a lot of details, which cause massive performance headaches later on.
I just noticed you said almost. Maybe this is the exceptional case you were thinking of :)
With MongoDB/Mongoose there absolutely are types and structures.
Most applications grow to the point that they have multiple database clients (it is a virtual inevitability).
Utilities that have to do something. Integration points. Etc.
In an ideal world these can all be completely tunneled through an API, but that is seldom the practice (different needs, different maintenance cycles, etc), whether in a RDBMS or a document model.
Above and beyond that, most applications see technical variations and evolutions of the things that contact it. Today you might be enamored with nodejs, tomorrow it's Go, and the next day it's noderust, etc. Having a technology-coupled surrogate for basic database functionality isn't a sustainable approach.
Mongoose mainly just provides a handy programmatic API in Node.JS to native MongoDB features. The querying power and types/structure (derived mainly from its inherent JSON-ness admittedly) are part of MongoDB, not the software around it.
Of course types and structures are useful but why do I need it in my database as well as in my app ? That's one reason databases like MongoDB have become popular because you can deal exclusively with your domain model and treat the database like an object store.
So you still have everything structured but not have to worry about annoying migrations.
>Of course types and structures are useful but why do I need it in my database as well as in my app ?
Do you write bug free code 100% of the time? I'm pretty good, but I definitely don't. And when there are bugs in my code, I'm grateful for a RDBMS with enforced referential integrity.
I've also had to work on projects where the initial codebase was scrapped all together. When that's happened I've found having the data in clearly defined columns and relationships immensely useful.
I have unit tests around my domain model so just as confident as I would be if I was using an ORM library. With the advantage of course of not having to worry about yet another library to manage especially working on mainly Java apps.
And like many are doing these days I do all my joins in my app so that I have the flexibility of moving objects into more appropriate storage mediums e.g. Redis or Solr without major refactoring.
I am not dismissing the benefits of having business rules in the database only that they aren't always necessary.
What about using an ORM? In Symfony2 for instance, we only think about objects, and they are magically mapped into MySQL or PostgreSQL tables by Doctrine2.
Postrgesql with no-sql extensions ( for when you may need flexibility), typed python or typescript or dart( or any language with optionnal typing) on the server, and typescripted js lib on the frontend I'd call it the Optional Typing Stack ( but ots isn't nearly as good as "mean" i must say).