I’m building an analytics and storage platform for entity location history. I’m a bit hung up on the database engine, though. On the one hand a graph database fits really well for the entity relationships. On the other hand, queries around the time based dimension (e.g. entity history and the history of a defined area) seem to fit better in an RDBMS.
I’ve been reading about different graph versioning models that would work for both at the expense of a LOT of extra vertices and edges. And an RDBMS could work as well if we’re willing to store a LOT of extra data to capture entity relationships.
Modeling data with two different primary dimensions (spatial, time) using two different databases feels like the ‘cleanest’ option. But here the tradeoff is more complex APIs, more complex ingestion, and probably slower response times.
I realize tradeoffs like this always come down to the use case. Do you optimize for reads or writes? How much complexity can users handle? What is the sensitivity to lag times?
My question to this community is if I’m missing something. Are there any red flags? For example, is it really unusual / bad practice to use two different systems vs just making one work?
gph is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.