
Ask HN: How would you chose a DB for a particular scenario? - DeathArrow
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.<p>If you didn&#x27;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&#x2F;website will grow, you will have the resources to hire people to deal with the database later.<p>Maybe spending a lot of time on picking the &quot;right&quot; database is a case of premature optimization?<p>But I cant&#x27;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.<p>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?<p>How can you tell which part of your data needs transactions and normalization, which part requires high speeds but doesn&#x27;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?<p>I think HN as many skilled users who can help me and others find answer to some of these questions.
======
BrentOzar
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.

~~~
DeathArrow
These seem wise words to me and is just what I did until now. Would continue
doing the same. I just wondered if there isn't a "database strategy" for
laymen.

But it seems - from articles I've read on the Internet - many projects got in
trouble trying to use exotic databases for which they didn't have enough
expertise.

------
brudgers
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.

