If you’re chasing billions of relationships, a graph shines with its edge‑first design – traversals are cheap and you avoid join‑fatigue. Relational tables still win when you need strict ACID, mature tooling, and complex analytical queries over wide schemas. In a huge app, mix‑ing them can make sense: keep core OLTP in a relational store and offload the relationship‑heavy parts to a graph for rapid discovery. The trade‑off is mainly performance versus familiarity and tooling support.

I’m actually working on a recommendation engine for a music streaming service. Every user has a tiny network of likes, follows, and playlist shares, and the whole thing is stored in a relational DB for billing and user profiles. The problem is that the recommendation algorithm wants to walk two‑hop or three‑hop relationships in real time – like “friends of friends who listened to the same tracks.” A graph database can answer that in milliseconds, but syncing every profile change back to the relational store takes a bit of glue code. I’ve been experimenting with an event‑driven pipeline that writes a stream of “relationship added” events to Kafka, then feeds those into the graph, and finally uses materialized views to keep the relational side fresh enough for the billing side. The challenge is keeping that stream consistent without slowing down user sign‑ups. It’s a trade‑off between eventual consistency and latency, but for most users the slight delay in the recommendation cache is acceptable.