3 ms·
Good reading, I've been curious! Some observations as a team active here. We're adjacent / complementary because we make graph db's (and regular SQL/databrick
by lmeyerov 4y ago
Good reading, I've been curious!
Some observations as a team active here.
We're adjacent / complementary because we make graph db's (and regular SQL/databricks/etc.) more actionable via rich & scaled graph viz workflows (analyst-facing) + graph automl (automation-facing), so sometimes end up working alongside graph db co's at enterprise/gov/tech customers so not just a silo'd db. I think we only saw ~1 production user of dgraph though, so entirely based on their competitors:
* Graph DB TAM: Neo4j revenue is probably around $200M/yr now, and probably another $100-200M across the other graph db vendors. (Market analysts say the graph db market today is $1B+ but seems rosy.) Importantly, because of analyst + AI use case growth in areas like recommendations, anti-fraud, cyber, etc., and streamlining of infra via cloud/docker/etc, everyone good is growing quite well, and I expect good YoY growth for everyone for at least 3 more years. The AI market likely a much bigger leap for graph, tho less clear for these graph db and especially cpu ones.
* GraphQL TAM: Agreed. But may be a bigger culture shock for a pivot. Not ready for Series B levels of expections. leading to...
* Revenue: Super risky, lacking big & growing revenue, to assume a Series A, and then a Series B (!), unless you have a special trick like having ties to the chinese government or being a successful serial founder people just trust.
* ... Tip for people looking at jobs: ask revenue / spending ratio + how many years in the bank when not profitable. If a b2b team can't make revenue work after $xM raised, they're on the path for stressful grinding, dilutive bridges & shutdown. VC treadmill grows expectations, so coming in from behind is asking for PE to take over or an acquihire where only the founders win.
- jandrewrogers 4y agoAn 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 agoagreed, 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