Ask HN: Best DB tech to build “Facebook” today? | Hacker News Reader

Ask HN: Best DB tech to build “Facebook” today?

6 pointsnnq6 comments

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?

View on HN

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/learn-to-stop-usin...

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

TLDR: 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

Relational databases have become popular because of their flexibility and that has not changed much through the decades. You can combine, aggregate, filter your data, tell the RDBMS in which shape you want it back, and speed up processing with the right indexes. And if you normalize your data properly, you can be confident that you won't end up with a pile of mud one day. Other databases like column oriented ones, or key-value dbms may be better at niche use cases like analytics, caching or very write heavy applications.

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.

Check out Azure Cosmos DB, it's multi-model and multi-API, and gives you the scalability, performance, availability, and consistency guarantees that few others do.

Does this lock you in to the Azure cloud, or can it actually be run on your own machines too?

Reply on news.ycombinator.com