Forgive me if I am just an old fossil but I am having difficulty understanding the attraction of migrating a schema to neo4j. This approach seems like it might be helpful for OLAP applications or for adding on such functionality but I don't see that there is anything there that would be very helpful for business transaction processing.
But perhaps I am missing the point?
Some specific and detailed examples of "analyze the codebase in novel ways", "unique advantages", and "moving from older v9 to newer web options from Progress" would probably go a long ways towards shedding light on what it is that this tooling actually does and whether or not it is interesting.
FWIW I do have some very old legacy code hanging around that I would be happy to try to modernize. But my pain threshold for trying new fancy new tooling is very low.
To clarify, our tool isn't migrating the schema, but the actual business logic. This may be a long winded response...
First, migrating may be the wrong word as there isn't a new system that uses the graph db for transaction processing. To understand, and I apologize if this is already known, but we need to talk about AI and how it works a little. Basically, AI is this tool that knows everything right, but to talk with it, you have to pass it a context window. At first, these context windows were very small, but recently they've grown in size with OpenAI's o3 reasoning model having a 200k token window. To give you an idea of this in the real world - yesterday I was exploring differences in output and a single program of around 7000 lines accounted for about 175k tokens.
Then there are two primary ways most people are using AI these days:
- “Needle-in-a-haystack” semantic search - ideal for huge windows.
- Quality search where the model fully grasps the input and can reliably return an output without mising ANY detail. I've found this to only be reliable on smaller chunks of say - up to 400 lines, but this is slowly increasing.
Now onto graph dbs. You made have heard of Cursor, Lovable, or Windsurf (just bought by openai). These tools work very well with newer modern stateless environments and smaller self-contained methods. They can index the codebases and will essentially summarize and embed each method of the application. They then store these full embeddings as a graph db - I'm assuming. The benefit of this approach is that when a user comes along, who's not that experienced, they can say "I want this this to be added". The AI embeds this query, it searches the graph for the most similar methods, and then the graph allows for related entities to be pulled back that symbollically match, but might not have actually been found using a purely semantic search (RAG vs graph). Now, they pass all that context into the window, the AI model takes it, and starts making suggestions or changes. But, this is where the problems arise. First, AI has a tendency to fully rewrite code blocks so if a section of code is larger as much code is, it will miss things on the rewrite. It will then try to refactor the code, and you inevitably start developing issues since these new tools are very bad at updating the rest of the code base to use this newly refactored method.
There's also the problem of context, and yes, newer models support larger windows (up to 10 million tokens for Llama), but these are mostly only useful for search (NIAHS). Beyond that, larger token windows really only benefit the vendor ( Cursor, openai, etc charge based on token use) since it's a little like reading 5-10 whole books for EACH question of a test.
Now, our tool. We take our full codebase and break down the logic into an independent database layer where we have the full business logic broken down to it's smallest detail. There is no programming language used within the db. There are many benefits to this design, and we've used it for years, but recently we realized the design of this system closely matched a graph db. To test this, we recently converted an existing progress db to neo4j, and ended up with millions of nodes and relationships. *Whether or not the graph db like neo4j is necessary is still being determined as we can rapid query our existing progress 4gl db, but the graph does bring a visual aspect, interesting ways to traverse the structure, and works more directly with modern cloud environments.
Whichever db we use, when combined with AI, and some enrichment methods to turn code into english, the outcome is a fairly complete code analyzer that seems like it can rival or beat even extremely experienced devs (30+ years). So to reiterate, there are other similar tools out there like - sourcegraph, tree-sitter, the newer VS code off shoots like Cursor, etc, except with ours, we can extract the key context without AI, and we can extract much more specific code trails than a related list of full methods. This means smaller context windows, less use for AI until needed, fewer mistakes (remember understanding across large context windows), lower costs, and easier access from less knowledgable devs or experienced devs.
Our tool is still in its infancy as we're still learning what's possible, but this is really where we'd love a partner like Progress since we're just one vendor, and the benefit of this would come from many. But, we think it's pretty reasonable to see it being used as a method to replace legacy devs, or it can be used as a method to determine modernization start points - which code could be easily refactored or is repeated, or as a security tool - find holes, or as a full system migration tool to newer versions of openedge or even other langauges entirely. There's even the potential to one day skip the compiler and go straight from the db to UI, which with AI seems like eventually this will be the standard - perhaps just with a layer to manage changes.
Hopefully this makes sense, but feel free to email me if you have any interest -
tscott@benedictgroup.com.
