Ask HN: In what areas are NoSQL Databases beneficial over Relational Databases?

On the topic of joins, I'd suggest if you're bumping into the joining limitation that you've chosen the wrong database for your needs. Having said that, a lot of it can be solved by rethinking your structure to take advantage of embedded documents.

For a personal project I used MongoDB over MySQL for somewhat faster prototyping. I was collecting a lot of data from the X display server during runtime and storing it into a database for querying later. Since there were a lot of different types of messages and I wasn't sure about which parts I wanted to keep, rather than building tables for each of them I converted them to JSON and piped them into a MongoDB collection.

I know this is not a good example compared to a production issue, however I think the reducing the amount of time need to get started with a project is very useful over something that needs a lot of configuring before it can be used.

In my opinion, the major reason to leave behind ACID databases is if you have reached the point where they can't scale up any more. If you have reached this point, you're probably a company with 20+ developers. There might also be very specific use cases where specialised databases are useful, such as a search index.

ACID gives you a lot of nice guarantees and it's silly to give it up if you have the choice.

As for MongoDB in particular, I would never use it for anything. It doesn't seem to do anything particularly well. There are better specialist 'NoSQL' databases that have actual benefits to fit your problem.

At work we use NoSQL for stats collection and aggregations. Our reason for choosing MongoDB is that we can have a rich document structure with multiple levels of nested documents. And with the rich update queries that MongoDB provides, we are able to update all of those nested documents in a single call, without having to update multiple documents.

That's one of the places where it made sense to use a NoSQL solution. Our documents had multiple levels of nesting, but no joins. We also use MySQL for our relational data, so in the end you have to pick and choose. All of the research we did pointed to NoSQL being a great fit for storing nested documents for stats collection. We haven't regretted following that advice yet.

I'm still a newbie so I have a hard time articulating this, just a couple years into my career. The "rule of thumb" that I've worked up so far is that document stores are great for records that are useful in isolation but are possibly heterogeneous in nature. (of course there's nothing stopping you from storing foreign keys and doing "joins", or just storing data with a strict schema). Logs and configuration are both simple use cases.

One example from my work is ingesting usage information from a variety of products, like a system that takes in information about all your utilities - power, water, gas, and so on. Each product will have its own attributes that's important to describing it. In a relational world, you might: add columns to your table as new attributes need to be described; come up with some kind of composite attribute system where you try to encode multiple pieces of information in one field; go for a star schema so every product gets its own table; or pivot so that each "record" is represented by multiple rows and the attribute's identifier is a field. Each of those approaches has their ups and downs but they're all present due to hard schemas. In a NoSQL world, a single table can have wildly varying records, each of which is useful on its own without needing to spread metadata into other tables.

I use MongoDB for periphery data to my applications, i.e. to aggregate data such as logs and events. It's also great to store things like reports in it due to the flexible structure. However, for my actual application database I always use SQL (MySQL).

The benefit: typically near infinite scalability with little loss of performance. It's super fast even when there's a lot of it.

The cost: transactions, relations. These are actually incredibly valuable things to have.

If you're storing billions and trillions of records that don't need relations, NoSQL is great. You'll keep your fast lookups and saves no matter how big things get.

This can matter a lot more if you're a start up with the goal of having trillions+ records some day. Your SQLServer will eventually not be able to scale any higher, and then what? Moving to Nonrelational from relational is so painful.

I would suggest to try using both SQL and NoSQL for some hobbies project. From there you should be able to experience the difference between these db. In a fairly complex application, you will see SQL, NoSQL and Redis, all exist for different purpose.

a good place for NoSql is where you don't know what data you are going to receive. e.g. i get weather data from a number of different sources in a number of different formats. the sources and formats change fairly regularly. i am able to extract the data in key/value pairs but don't know which keys will be in any given set of data. with nosql you can extract any key/value pair and save it to the database without needing to parse the data

NoSQL is amazing when you have non relational data. Think of it as a giant, distributed hash table. Hash tables are awesome and wicked fast. But toss in relations and now you got some interesting problems. RDMS solves that for you but scaling is now harder. At least in my opinion anyway. You can still use NoSQL in these situations but you're typically duplicating data or indexing it yourself so you can refer back to it.

It's all about trade offs. If you're small just pick the best one for the job at hand. When you need scale you can usually hack either into scaling well enough.

When clients ask this question, I always suggest starting with a good SQL solution and then figure out why it won't work. So if you're not hitting any major problems with MySQL or SQL Server, then NoSQL solutions will just be incredibly labor intensive for, from your perspective, a loss in functionality. Each NoSQL database is different and designed to approach problems from SQL databases differently. For Mongo, this is having a very flexible denormalized schema with very fast reads. However, companies such as Pinterest and Facebook have found they can accomplish this with MySQL or Postgres through different data modeling. I think the reasons for NoSQL become much clearer when trying to build applications that do not keep a normalized data model.

With RDBMS you have to design the schema first, with NoSQL you don't need to. This is nice when you're dealing with very diverse data (or data you don't even know how it'll look like) or are prototyping. One thing I like about this: You can store your data as it is, you don't have to fit it into your model / world view. You can make sense of it later.

At some point you'll probably have to deal with schema anyway. If this comes at a later stage, you'll have to deal with a lot of diversity and inconsistency on potentially many points. This can become much more painful and time consuming than having dealt with it from the beginning.

If you're thinking about NoSQL as something like a simpler, modern SQL alternative, you're probably having a faster start and a lot of problems in the long run.

Scalability is something, NoSQL databases have for them, definately.

For me it's all about not having to define a schema. I can just take my JavaScript object and insert it in a collection. Sure, I know you can do this in PostgreSQL and I might switch.

The only time you should use NoSQL is when you have no other choice. For example, if your database is too big to fit on one server, or you need a massive number of writes per second. Otherwise SQL will give you better performance, much more security, and better data integrity.

NoSQL is for heterogeneous data that is read in a homogeneous manner, whilst relational excels at homogeneous data read in a heterogeneous manner. If your schema is constantly changing, relational is painful, conversely writing reports against a NoSQL datastore hurts too.

If you come from an RDBMS, you're probably going to dislike MongoDB. I like it for prototyping/MVP but once the schema settles down it's time to move.

However, NoSQL does not start and end at MongoDB, no way. There are lots of different flavours, from huuuuuuuuge key/value stores, to timeseries, to write-one-read-many document stores, to remote syncing mobile app datastores and probably loads of other types that I haven't used yet.

So figure out why you want to use NoSQL (CV building can be a reason too) and play around with some toy installations.

In the early days of companies MongoDB has helped me tremendously with development speed because it is schemaless. Since Postgres 9.5 I'm trying to replicate the speed with Postgres binary JSON but most access libraries are still SQL oriented and I haven't achieved the speed of MongoDB with Scala/Rogue yet.

The two things, that Relational Databases typically don't do well: 1. High availablity and no downtime, ever. 2. Unlimited scalability of all operations, including writes.

Honestly, many (most?) NoSQL databases also don't really do them well. If you need these two properties, the only valid choice is really a master-less, shared-nothing database system. E.g. Apache Cassandra.

I find them useful in many scenarios:

- Bootstrap projects with open or changing requirements. A relational model is usually harder to maintain.

- Storing and querying objects with complex structures, such as those received from APIs.

- Having a single programming language across your entire application stack (ie MEAN). Sometimes comes up as a "should" or even a "must" requirement.

- Fast and simple object storage (ie sessions).

    SELECT data->>cust_id AS cust_id, SUM(data->>amount)
    WHERE data->>status = 'A'
    GROUP BY data->>cust_id;

    SELECT DISTINCT data->>cust_id;

First of all, this question is similar to asking in which cases non-cars are beneficial over cars. Cars cover many use cases but sometimes bicycles perform better in heavy trafficked cities, planes carry you faster to the other side of the world but you need a cargo ship to move tons of containers there. That list goes on and on, up to less common activities like jumping fences (horses) or very rare ones like going to the moon.

Now, there are many use cases for non relational data stores. There are already many answers in the comments but first you have to ask yourself what you need the data store for. In the cars analogy it's where you need to go, how fast, carrying what, etc. Do you need a glorified hash table? Redis is good at that. Do you need very fast queries? You might try Cassandra but be very careful at defining in advance all the queries you're going to run: if you need sorted results you have to plan the columns for them. See http://www.planetcassandra.org/blog/we-shall-have-order/ and remember that NoSQL doesn't always mean schemaless.

Sometimes the choice is about the tradeoffs between the ease of use, installation and planning. MongoDB maybe doesn't particularly excel at anything but you install it with an apt-get (check in advance which version you get) and adding replication is easy. However you better start planning at least a partial schema for your documents quickly or you'll get ton of litter in your database. On the cons side, its native JS based query language is awfully verbose and complex compared to almost anything else, ORMs and especially SQL. Luckily we don't need the console much.

To recap: ask yourself which data you have to manage and why, then google for a database that optimizes your use case and check it against the posts at https://aphyr.com/tags/jepsen which does a super-excellent job at finding out how dbs fall apart in extreme but realistic cases. Often you'll find that a relational database is good enough. Other times you'll have to choose between relational and one or two categories of NoSQL. There are very few mainstream RDBMs but there are zillions of NoSQLs so the choice might not be obvious. Final car analogy: car + tent or camper van?

If you need data integrity you will need a RDBMS.

Different NoSQL platforms solve different problems. Graph databases can build and query relationships between entities with significant speed. Mongo has been mentioned a few times because it's easy to iterate development with a schema-less database, but it's also fantastic when dealing with class based structures with sparse attribute populations (e.g. a CMDB). Cassandra's notion of an always available database is a key foundational element in high-scale devops environments. Scylla offers incredibly fast transactions (they advertise 1M transactions per second per server). There are XML databases that store and query documents in ways that are easy for developers to translate (i.e. xpath). There are databases like Axibase that are built for time series data. BayesDB is easy to query for statistical inference.

It's very easy to fall into the trap of "everything is relational" or "I could do that with Postgres/Oracle/etc". There are a lot of problems that have good RDBMS centric solutions, but you don't have to look too far to find end users or developers who are unhappy with the RDBMS solutions that they work with on a daily basis.

NoSQL is all about missing useful features (such as integrity, transactions, query flexibility), that you unfortunately have to drop if you want to be able to scale in certain ways. Thus, NoSQL dbs are practically worthless until you get to a point where your SQL database won't work any more. At this point, you need to evaluate exactly what is it that your SQL db cannot handle, and switch to a different product accordingly. For example, you would switch to Aerospike if you need to scale writes.

Depends, there are many types of NoSQL databases, that all have different focuses.

SQL started getting big because it was the one size fits all approach that worked 90% of the time. In fact it got so big, that universities started to teach only them when they talked about databases in general.

But there are many problems, where SQL is not suited.

If you got hundrets of terrabyte of data you need to analyse, you're probably better of with a Hadoop cluster.

If you need inter process communication, Memcached or Redis is worth considering.

If easy db-sync is your main goal, couch/pouch-db is probably a good choice.

etc. pp.

But these three DBs alone are so different, that they can't be compared like MySQL and PostgreSQL can.

typically the advantages of nosql are along the lines of schema-less, speed of writes, reads should be faster typically as well.

speed of writes, there are no constraints that need to be checked with nosql (typically), it's like writing a value into a hash map. with sql there needs to be a check for multiple constraints: uniqueness, null, datatype, etc. if there's a relation then it needs to check those constraints as well.

the whole thing about rdb's is that they're trying to normalize data where possible, you deal with id's and the fields of the table can change without you needing to propagate these changes to other places. in nosql, if you have relational data then you have to manually make sure all these changes are propagated, pretty annoying if you ask me and quite error prone, you end up writing logic an rdb already optimizes for you. take "cascaded deletes", too, this is manual in nosql.

the best usage of nosql is if you have stagnant data, and you need to write it quickly, take a log file contents, for example, or if your data consistency requirement is not that critical (let's say you implement likes for a web post system, if you're missing 300 here or there, not a huge deal). other cases are things like counters, if you have a game where you're tracking scores, things are changing rapidly , but there's really not a lot of relation with other data, redis is a great example of this type of nosql storage, built in incrementing counters.

most of the time when someone brings up nosql for an application, my initial reaction is that it's a premature optimization, for a lot of data, there are tight relationships and rdb is great for that. but i tend to see that you need both in many cases.

No mention of BigTable so far - ACID compliant NoSQL with transactions IIRC. But you have to host with Google. (For at least the data store component)