Graphistry gets used with a lot of graphdb + non-graphdb projects for the UI tier, so I now think of it sociotechnically on 2 dimensions: - Approachable semant

Graphistry gets used with a lot of graphdb + non-graphdb projects for the UI tier, so I now think of it sociotechnically on 2 dimensions: - Approachable semantics: Graph-y queries like untyped entity 360 views are way easier to write in graph langs. This matters for programmer adoption. But tabular systems can be simpler to implement for doing great on all sorts of things, so other tricky tasks on SQL got industry weight over decades as the market rewarded graph DBs more for doing great on graph tasks and just ok on non-graph. - Diverging performance for sweet spots. Graph DBs get optimized for graph queries that SQL DBs struggle at, which matters for big enterprise contracts => most revenue. There are multiple approaches -- handling heavy concurrent small read/write queries, big whole graph compute, fancy iterated symbolic reasoning, horizontal scaling, GPU acceleration -- and while in theory you can combine most, reality is even with VC money someone like TigerGraph will have great scaling but not GPU speed/efficiency of cuGraph, and neo4j wins at usability. SQL engines will have better specializations for HA, GIS, time series, etc. In theory those can be special indexes in graph DBs (I think neo4j uses lucene for text indexes?), and vice versa within SQL. But practically, it takes a lot of time and $$$, so compounding engineering years fueled by enterprise $ is playing out. So in both cases, we see SQL taking compounding benefits for general purpose use, while the niche graph space goes deeper in its sweet spot. Neo4j and maybe TigerGraph might be 5-10 years away from being good general databases, especially with the rise of open source for specialized index types and ecosystem adapters, which is interesting to consider. So does SQL eat graph before graph eats SQL, or more timely, will the graph DB niche grow or shrink? It's actually a quite interesting time in this space. In particular, the increase in data scales, rise of NLP knowledge graphs, and need to fuel AI/automation systems with things like 360-views of entities has grown the modern need for graph DBs. Still a small % of DB use cases, but huge wrt enterprise/tech market size. Separately, the new ubiquity of large & high-fidelity operational data (clicks, logs, transactions, sensor reads, ..) have led to a corresponding ubiquity of behavior and relationship questions, including over log and SQL DB systems, which are ~100X bigger than the graph db market. This has been fueling our corner of graph intelligence (viz, BI+automation, AI) space. So we and basically all of our graph partners are hiring (we do intl remote!), and I encourage you to check all of us out :)