
Ask HN: Best DB tech to build “Facebook” today? - nnq
If you were building something like Facebook (or Google+ etc. - something quite isomorphic to a social network), what database technology would you choose?<p>A classic <i>relational DB</i> like MySQL, an extra-featured-RDBMS like Postgres, a super-scalable one like CockroachDB? Or a <i>column-oriented</i> RDBMS? Or maybe a <i>document DB</i> like Mongo? Or jump in and pick an <i>actual graph database</i> since your data would look like graphs anyway (eg. Neo4j or Arango DB).<p>Or a 2 tiered system with a &quot;core&quot; relational or column oriented system, and a graph DB for advanced analytics that might require graph traversals?
======
sahin-boydas
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...](https://medium.com/@Pinterest_Engineering/learn-to-stop-using-shiny-
new-things-and-love-mysql-3e1613c2ce14)

~~~
nnq
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
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

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

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

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

