For sub-billion graph queries, we have been doing in-memory via GFQL that runs graph queries & analytics on top of pandas (columnar CPU dataframes) and cudf (columnar GPU dataframes). Sub-billion is typically small enough that single node is fine. We began dev after years of being annoyed at having no good simple OSS in-process solution for small graphs like these. Avoiding jumping architectural hoops around dealing with multiple systems of record infra is nice, as can often just do in the compute tier.
Once big graphs get involved, scalable systems, and especially those that seperate storage from compute & price accordingly, get much more interesting. We work with our partners like databricks, Google spanner, AWS Neptune, etc, who have different sweet spots that really depend on workload and context, they're all pretty different. OLTP vs OLAP, etc.
Comments
For sub-billion graph queries, we have been doing in-memory via GFQL that runs graph queries & analytics on top of pandas (columnar CPU dataframes) and cudf (columnar GPU dataframes). Sub-billion is typically small enough that single node is fine. We began dev after years of being annoyed at having no good simple OSS in-process solution for small graphs like these. Avoiding jumping architectural hoops around dealing with multiple systems of record infra is nice, as can often just do in the compute tier.
Once big graphs get involved, scalable systems, and especially those that seperate storage from compute & price accordingly, get much more interesting. We work with our partners like databricks, Google spanner, AWS Neptune, etc, who have different sweet spots that really depend on workload and context, they're all pretty different. OLTP vs OLAP, etc.