It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
There's really only one question to ask: is your data model relational?
If your model includes discrete entities connected in a dependency graph, use a relational DBMS or you will more than likely regret it. If you've got strictly hierarchical or arborescent data with few to no interconnections between entities, then it's time to look into document dbs. I've said it before and I'll say it again: if you can't articulate why you need something other than an RDBMS, you need an RDBMS.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
There's really only one question to ask: is your data model relational?
If your model includes discrete entities connected in a dependency graph, use a relational DBMS or you will more than likely regret it. If you've got strictly hierarchical or arborescent data with few to no interconnections between entities, then it's time to look into document dbs. I've said it before and I'll say it again: if you can't articulate why you need something other than an RDBMS, you need an RDBMS.
I agree. Is there a way to build a realtime system over a relational database? The go to platform is Firebase but an RDBMS makes more sense to me
What does "realtime" mean in this context? Properly designed and indexed relational databases are plenty fast until you get to extreme scales.
Look into Phoenix, it's got good RDBMS support, and excellent soft real-time performance because it's backed by the BEAM VM.
I totally agree with this. LOL. Still trying to wrestle with Ecto though.
This might help blog.getbotmetrics.com/150x-speedu...