4 ms·

MySQL then, MySQL now. A great read from Pinterest engineering: Learn to stop using shiny new things and love MySQL https://medium.com/@Pinterest_Engineering/

• nnq 7y ago
  Thanks for the link and input. Any reason a team already more familiar with Postgres than MySQL would go for the latter in this case, is MySQL somehow more suited for such scenario? Or your just mean "just pick a RDBMS", so choice of MySQL over Postgres over let's say CockroachDB (which should be a drop-in replacement for Postgres if-and-only-if you stay away from fancier Postgres features like array and JSON fields, stored procedures etc...) is not your point? (As context, I tend too to pick a RDBMS in general, and Postgres in particular, but I saw projects where there was a huuuge impendance mismatch between the business logic and the relational model, data was simply unimaginably awkward to think of it in a relational model and manipulate it as such, it was all trees in trees in trees, mongo/couch model all the way and mongo was boring enough to be a good fit there.)
  • env1234 7y ago
    TLDR: https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis Honest answer, just go with what your team is mostly familiar with. Surely, when you're programming, you will have a relational-mapping layer between your code and database, right? It shouldn't be too difficult to migrate from one DB to another - DBAs are there for a reason, consult your team's experts