[lolinder]

To add to this: with Postgresql's JSON type, it's very easy to mix the two. We use relational data for most things to get the benefits of an enforced schema, but in places where freeform is preferable we stuff that data in a JSONB column. I can't think of any projects that would need more flexibility than that provides.

[techdragon]

Adding to this is the support for queries on the JSONB column which combined with computed table columns and the support for indexes (including sparse indexes) on JSONB columns. You can throw a bunch of stuff you don’t know how to deal with yet that you know you will need to deal with later... then gradually massage out the important parts, expose them to code using the table in a normal SQL style manner, test if things make a difference to indexes, and then eventually promote relevant information out of the unstructured data in the JSONB column up to a place in the fully specified SQL table with an appropriate column type and everything.

It’s a fantastic way to build an exit strategy for situations where original developers a picked NoSQL database and current developers want to replace it with a more structured SQL database.

[databrecht]

Freeform flexibility is one aspect, but a document-style could also simply be a preference for how you want to structure your data or typically has an impact on how joins happen (if the document-database offers joins). Those joins will work in a graph-like fashion instead of how flat sets are typically joined. Or a nested document could be an optimization to provide data in the exact format that your client wants to see it. Although some document databases have popularized the idea that you should join in the client because they didn't provide joins initially, it doesn't have to be that way.

Mixing paradigms in one database is probably going to be happening more. Just like Postgres is offering a 'document' style, some document databases are offering documents with relations. It wouldn't surprise me to see document databases offer optional schemas. I think that the future is a mix of options and tools in one database (which JSONB columns are a first step for). Depending on the situation we'll just model differently. The best database might become the one that makes us use these different tools most elegantly together. The difference between a document and a table is only a 'flatten' and a 'schema' away.