This made sense for product catalogs, employee dept and e-commerce type of use cases.
But it's an extremely poor fit for storing a world model that LLMs are building in an opaque and probabilistic way.
Prediction: a new data model will take over in the next 5 years. It might use some principles from many decades of relational DBs, but will also be different in fundamental ways.
GraphQL was designed to add types and remote data fetching abstractions to a large existing PHP server side code base. Cypher is designed to work closer to storage, although there are many implementations that run cypher on top of anything ("table functions" in ladybug).
Neo4j's implementation of cypher didn't emphasize types. You had a relatively schemaless design that made it easy to get started. But Kuzu/Ladybug implementation of cypher is closer to DuckDB SQL.
They both have their places in computing as long as we have terminology that's clear and unambiguous.
Look at the number of comments in this story that refer to GraphQL as GQL (which is a ISO standard).
Got it. I didn't realize. Checking out the docs, looks like GQL is based on Cypher. So in the thread people were talking about it, just calling it GQL as the common name, not Cypher as the original name and I missed it.
Store your graphs in Parquet files on object storage or DuckDB files and query them using strongly typed Cypher. Advanced factorized join algorithms (details in a VLDB 2023 paper when it was called Kuzu).
Looking to serve externalized knowledge with small language models using this infra. Watch Andrej Karpathy's Cognitive Core podcasts more details.
For every person trying to move an old code base from COBOL to Java to remove tech debt, there are an equal number of people who want rewrite a working C++ code base in Rust/Go/Zig.
Leaders who know that it's a people problem and who have read the Jerry Weinberg book know both sides of the problem.
Anyone using it in prod even with the beta status?
reply