[bluefirebrand]

I no longer buy the "use relational databases for relational data, use NOSQL for non-relational data" mentality.

Basically all meaningful data in an application context has relationships. There is no real such thing as "non-relational data"

Instead the question really is do you want a planned, enforced schema or an unplanned, freeform one.

Use a SQL database for the former.

Take a long look in a mirror and question the decisions that made you the way you are if the latter.

[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.

[simplerman]

Having worked with NoSQL apps, I would say that NoSQL simply move the burden of maintaining data integrating inside the application code. I would recommend default should be SQL and NoSQL should be used only if it really is impossible to do it in SQL.

[databrecht]

Exactly, but it goes further than that. The mentality never made sense since the term NoSQL never made sense to start. It's amazing how many people use a term that just originated from a meeting to talk about alternative databases. How we keep using it, although it's practically impossible to say what NoSQL is. Depending on whom you ask that term means different things. This is a very good introduction to the term: https://www.youtube.com/watch?v=qI_g07C_Q5I

Graph databases are considered 'NoSQL' yet they have relations and transactions. Schemaless is often also one of the properties give to NoSQL, but it's also a bit strange to consider that a NoSQL attribute. Some traditional databases offer schemaless options and databases like Cassandra has schema yet is considered NoSQL. I work at Fauna which has relations, stronger consistency than many traditional databases. It is schemaless at this point but that might change in the future. Since it doesn't offer SQL it's thrown into the NoSQL bucket with the assumptions that come along with it.

None of these one-liners in computer science make sense IMHO and we listen way too often to colleagues who use them. Similarly "Use SQL for enforced schema" might be accurate in many cases but in essence it depends on your situation, and we need to do research about what we use instead of following one-liners ;)