We all know there is a ton of DB technologies out there and "apparently" one size doesn't fit all.<p>There are multiple ways to evaluate and choose database technologies, but there is no common ground/sense about the process developers or an IT professional follows to select the DB they are going to use (or buy).<p>Some might choose primarily by performance, others choose by the number of features or even by the trustability of the brand offering it (e.g AWS, GCP).<p>That said, what's process you normally follow to choose database technologies for your company/project?
You have to define the problem to figure this out.<p>Me personally, I am a fan of multiple smaller db's that are purpose fit (regardless of application architecture). e.g. user/security, payments, logging, analytics, search etc.<p>Doing this lets me pick the best tool for the job and also generally keeps the data to an isolated area which makes backup/recovery easier and also allows you to apply tighter security standards around them as needed.<p>Another factor you have to consider, distributed databases change the backup/recovery strategy drastically as does data growth and size attributes.<p>As for technology, I generally stick with relational DB's (postgreSQL is my go-to) unless there is a specific problem to solve that I can do better/easier/faster with another tool. As an example, I might ship data (logging or otherwise) into elasticsearch for searching. I also have no issues using any of the DB's from AWS that are based on open source databases, but I don't generally use DynamoDB as an example (not that I wouldn't just haven't seen a good argument given other options and costs etc).<p>I also use S3 a lot for backups and for json stores. Personally, I have always wanted to play with using ES as my query tool with all the data stored in S3 itself. Wouldn't work for everything but seems pretty damn reliable and scalable. Even the index snapshots could be stored in S3 for recovery purposes if needed.
I think it depends on your product and where it is at in its lifecycle. If you are building a new product or service, just use an option that is sufficiently stable (Postgres, MySQL, etc). If you are thinking of migrating from one technology to another, you need to figure out which metrics you are trying to improve and see which alternative(s) would provide the performance improvement you are looking for.<p>That said, when I am making the decision myself, I just go with Postgres.
I use PostgreSQL, unless I need/want high availability then I use master-master Percona/MySQL.<p>If it's someone else's money then I use RDS PostgreSQL with Multi-AZ.