3 ms·

An important aspect of graph database TAM is that the current market size is somewhat defined by the poor scalability and performance of existing graph database

An important aspect of graph database TAM is that the current market size is somewhat defined by the poor scalability and performance of existing graph databases. Many interesting applications simply don't fit within the limitations of current graph database platforms, and those limitations haven't changed much in the last decade. I would agree that the "database" part is not that important. It is the notion of scalable graph analysis that sells a platform. However, for sufficiently large graphs (most of the interesting apps are in this class), GPUs often don't help much versus CPUs in my experience.

lmeyerov 4y ago
agreed, and we've heard heart-attack-level pricing pushback for the few db's that do scale well likewise, for analytics, we're seeing a bit of a split: - DB side: Traditional real-time graph analytics (pattern search, ...) can often be done on extracts from KV-store level queries, so just use those and post-process the compute ("extract 1-2 hop neighborhood, then cross-product in lang xyz"). Like the old Titan -> Cassandra days. GPU can be nice for accelerating a simple inferencer here (e.g., a T4), but not necessarily the actual fetch. Gets a bit more blended in 'real' knowledge graphs, but that's more R&D. (Edit: I believe Facebook's at-scale graph engine successfully runs on top of SQL for related reasons.) - AI side: Massive interest in GNNs (we're active here!) as starting to eat the lunch of the result quality that traditional graph analytics can give. Basically the pendulum swinging back to graph for areas like recommendors & classifiers. Shopping carts, fraud, cyber, etc. These had gone the way of ML + AI systems for awhile now, but with GNNs becoming practical, best of both. And... GPUs matter over CPUs again. Funny enough, we're getting into a bunch of vector search scenarios, and because of our particular scale & query richness needs... looking at OSS graph DBs and pairing with GPU nodes. /insert "why not both" meme here
- HyperSane 4y ago
  "the few db's that do scale well" Which ones?
  - random3 4y ago
    +1 - curious

lmeyerov 4y ago

agreed, and we've heard heart-attack-level pricing pushback for the few db's that do scale well likewise, for analytics, we're seeing a bit of a split: - DB side: Traditional real-time graph analytics (pattern search, ...) can often be done on extracts from KV-store level queries, so just use those and post-process the compute ("extract 1-2 hop neighborhood, then cross-product in lang xyz"). Like the old Titan -> Cassandra days. GPU can be nice for accelerating a simple inferencer here (e.g., a T4), but not necessarily the actual fetch. Gets a bit more blended in 'real' knowledge graphs, but that's more R&D. (Edit: I believe Facebook's at-scale graph engine successfully runs on top of SQL for related reasons.) - AI side: Massive interest in GNNs (we're active here!) as starting to eat the lunch of the result quality that traditional graph analytics can give. Basically the pendulum swinging back to graph for areas like recommendors & classifiers. Shopping carts, fraud, cyber, etc. These had gone the way of ML + AI systems for awhile now, but with GNNs becoming practical, best of both. And... GPUs matter over CPUs again. Funny enough, we're getting into a bunch of vector search scenarios, and because of our particular scale & query richness needs... looking at OSS graph DBs and pairing with GPU nodes. /insert "why not both" meme here

HyperSane 4y ago
"the few db's that do scale well" Which ones?
- random3 4y ago
  +1 - curious