When building an application, we tend to select a database technology based on its transactional characteristics. We consider raw performance, API style, consistency model, data model, and deployment architecture. That’s about as much as your service cares about: can it meet the functional and non-functional requirements for the production behavior of the service?
Even in a microservice architecture where no other application is allowed to access the service’s database, that database probably has a bunch of other clients. You may not think about these when making your selection, but how well or badly your database supports them has a big effect on its eventual success.
- ETL connectors. Your company has some kind of ETL or ELT to feed bulk data from your service to analytical processing.
- PII Discovery and Classification Tools. These tools are part of data governance and will be a horizontal capability. They look through your schema and samples of your data to see if there is undeclared PII.
- Backup and Recovery. Whether this is something like cross-datacenter replication or “cold” storage of backup files, everybody’s got one. (And by the way, have you tested your backups lately?)
- Query Optimization. Your service doesn’t need this but you do. (Especially in the cloud where performance equals savings!)
The horizontal tools are probably licensed at an enterprise level. Your company has to pay for the connectors to each different type of database in use. So if you’re the only user of a particular DB technology, that connector cost (whether license fee or labor to build it) is part of the cost of choosing that technology. It’s not a trivial component of the overall price tag, so make sure you understand the full cost/benefit equation when making your choices.