“Which database is the best?”
Superlatives are dangerous. They pressure you to line up the alternatives in a row, judge them all, make the perfect decision.
This implies that databases can be compared based on internal qualities. Performance, reliability, scalability, integrity, what else is there?
We know better than that. We recognize that relational databases, graph databases, document stores etc serve different use cases.
“What are you going to do with it?”
This is progress; we are now considering the larger problem. Can we define the best database per use case?
In 7 Rules of Effective Change, Esther Derby recommends balance among (1) inner needs and capabilities, (2) the needs and capabilities of those near you, and (3) the larger context and problem. (This is called “congruence.”)
“What is the best?” considers only (1) internal qualities. Asking “What are you doing with it?” adds (3) the problem we’re solving. What about (2) the people and systems nearby?
Maybe you want to store JSON blobs and the high-scale solution is Mongo. But is that the “best” for your situation?
Consider:
- does anyone on the team know how to use and administer it?
- are there good drivers and client libraries for your language?
- does it run well in the production environment you already run?
- do the frameworks you use integrate with it?
- do you have diagnostic tools and utilities for it?
Maybe you’ve never used Mongo before. Maybe you already know PostgreSQL, and it already runs at your company. Can you store your JSON blobs there instead? Maybe we don’t need anything “better.”
The people we are and systems we have matter. If a component works smoothly with them, and is good enough to do the task at hand, great. What works for you is better than anyone else’s “best.”