Skip to content
loading...
Discussion
markdown guide
 

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

 
 

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.

 

What does "realtime" mean in this context? Properly designed and indexed relational databases are plenty fast until you get to extreme scales.

 

From your other comment, you mention realtime systems. This is a different problem from a database and has more to do with communications. Firebase just packages things together for you. For example, Postgres (a relational DB) has LISTEN/NOTIFY which can allow listeners to distribute messages to connected clients. Or you can skip integrating the comms with the database altogether and just notify connected users completely from code when things happen.

 

Redis is also a possibility if your data model is pretty lightweight and the main focus is on publishing/subscribing to events.

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

John Paul Ada profile image
BA Psychology grad turned software engineer. Tech Evangelist. Data Scientist Wannabe.