Even handle very large amounts of data and

Even within these two categories there are a lot of choices, and it’s an extremely important decision that is hard to change later. So which should you use? It’s all about tradeoffs?—?no database is perfect for every situation. Generally, these are the most important things to consider:Scalability. Most popular databases can handle very large amounts of data and support thousands or millions of users of your product. But SQL databases will hit a wall at some point down the road without an easy path forward. If you’re planning to be the next Facebook, it will save your future engineering team a lot of pain to use a more scalable database. Even if they end up migrating to another database for reasons you can’t anticipate, starting off with an unscalable database forces their hand and could rush an important future decision.Availability & Distributability. As discussed above, availability is distinct from (and sometimes in conflict with) scalability. If a 5 second outage would really hurt your business, then availability is important.Maturity. It is important that your database works. It needs to be stable, fast, and bug-free. You don’t want to risk losing or corrupting your data; even if you schedule regular backups, restoring backups can take hours or days, which could kill your business. One of the biggest mistakes I made at my last company was choosing a database that was only a few years old and therefore hadn’t been through the wringer. We spent a lot of time fixing problems with the database, often requiring us to contact the database creators, when we really just wanted to spend our time building our product.Speed. Pretty much any database measures time in milliseconds. That may sound fast, but the difference between 1ms and 10ms could matter to a lot of applications. Some databases are inherently faster than others, and some optimize the speed of certain operations (like reading existing data) at the expense of other operations (like writing new data). Which is more important depends on your application.Consistency. Consistency is great, but might not be worth the cost. Engineers who haven’t worked with eventually consistent databases might be scared of them and over-emphasize the importance of consistency, but such databases are slowly gaining acceptance as people realize what they are giving up by insisting on consistency.Data representation. I put this last because in my opinion it is overrated. People often look for a database whose data format “feels like” the data they’ll be working with, such as a graph database for social networking applications. In reality, pretty much any database could be made to work with pretty much any application, although some would be clunky integrations that perform poorly. The main reason I think it’s overrated is that engineers have been taught for decades that “relational is right” which biases experienced engineers toward SQL. (Sorry. I made it almost to the end without expressing my own opinion.)