How would you chose a DB for a particular scenario?

Question

I am humble Web developer, not skilled in databases and I know just the basics: write SQL code, what normalization is, how to use indexes, impose restrictions, use views and stored procedures.If you didn't have the resources to hire the a competent architect and DBAs, the conventional wisdom said that you are fine with any of MySQL, Postgres or SQL Server for almost any task and use case and if the app/website will grow, you will have the resources to hire people to deal with the database later.Maybe spending a lot of time on picking the "right" database is a case of premature optimization?But I cant's stop to wonder if there are any rules, guides on how to pick the database engine, based on use-case, knowledge you have, hardware resources needed, trade-offs in CAP theorem and whatnot.While I use an ORM both at work and for personal projects, that will allow me to switch the DB but I only have to chose between a few relational and established DBMS. What if the project would be better with a NoSQL DB? What if a NewSQL would be better? Or maybe a combo of RDBMS and NoSQL?How can you tell which part of your data needs transactions and normalization, which part requires high speeds but doesn't require consistency, which part should be distributed and on what level, which part needs to be highly available? And after you know all of that, how do you pick the database or combination of databases?I think HN as many skilled users who can help me and others find answer to some of these questions.

BrentOzar · Accepted Answer

If you can't afford database people, pick the database that you have the most experience with. The databases you mentioned (MySQL, Postgres, and SQL Server) are all good enough for most projects - as long as you know how to use one of them.
Generally, though, it's a bad idea to pick a database that you don't understand, thinking that the database is somehow "better." A good musician can make a bad instrument sound good, but a bad musician isn't helped by playing a Stradivarius: your knowledge is the better differentiator than the instrument quality.
If you're one person doing side projects, I'd also strongly recommend a managed database as a service. If you're not trying to become a database administrator, then every hour spent managing databases is distracting you from producing the value that will bring you customers. Customers don't pay you for your database management skills: they pay you for the value your app produces. Focus on the app code and its value, not testing your database restores.

brudgers · Answer

For a lot of data workflows, document search might be an alternative to what people usually mean when they say "database." Store documents. Extract metadata. Search the metadata. Retrieve the document or some of its metadata.For example, Google. Good luck.