A recurring theme in these notes has been that for any given problem, there are several solutions, each with its own pros, cons, and trade-offs. For example, when discussing storage engines in the related discussion, we examined log-structured storage, B-trees, and column-oriented storage. When discussing replication in the related discussion, we considered single-leader, multi-leader, and leaderless approaches.
If you have a problem such as “I want to store some data and look it up again later,” there is no one right solution, but many approaches that are each appropriate in different circumstances. A software implementation typically has to pick one particular approach. It’s hard enough to get one code path robust and performing well; trying to satisfy too many use cases with many features is likely to lead to poor implementations of those features, compared to specialized tools.
Thus, the most appropriate choice of software tool also depends on the circumstances. Every piece of software—even a so-called “general-purpose” database—is designed for a particular usage pattern.
Faced with this profusion of alternatives, the first challenge is to figure out the mapping between the software products and the circumstances that are a good fit. Vendors are understandably reluctant to tell you about the kinds of workloads for which their software is poorly suited, but hopefully the previous chapters have equipped you with questions to ask that will help you read between the lines and better understand the trade-offs.
However, even if you perfectly understand the mapping between tools and circumstances for their use, there is another challenge. In complex applications, data is often used in various ways, and one piece of software is unlikely to be suitable for all of them. Therefore, you inevitably end up having to cobble together several pieces of software to provide your application’s functionality.