Ask HN: Best DB tech to build “Facebook” today?
If you were building something like Facebook (or Google+ etc. - something quite isomorphic to a social network), what database technology would you choose?
A classic relational DB like MySQL, an extra-featured-RDBMS like Postgres, a super-scalable one like CockroachDB? Or a column-oriented RDBMS? Or maybe a document DB like Mongo? Or jump in and pick an actual graph database since your data would look like graphs anyway (eg. Neo4j or Arango DB).
Or a 2 tiered system with a "core" relational or column oriented system, and a graph DB for advanced analytics that might require graph traversals?
6 comments
[ 3.0 ms ] story [ 23.2 ms ] threadA great read from Pinterest engineering: Learn to stop using shiny new things and love MySQL
https://medium.com/@Pinterest_Engineering/learn-to-stop-usin...
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.)
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
A social network is mainly about simple CRUD and combining data in various ways, so it is primarily a matter of taste which RDBMS you use. So you should probably stick to what you know best.