When you see 25 agent definitions, how do you know they are good? How do you know it’s better than 10 or 5 or 1? Is a project with 100 agent definitions better?

Youtrack was made long before Kotlin so I suspect the rewrite just wasn't worth it

You can port files from Java to Kotlin by pressing a button, but Jetbrains has generally not done bulk ports. They leave it up to individual devs to convert a file when it's being worked on, if the diff and VCS history pollution is worth it.

I worked in a startup whose value proposition was largely derived from using graph data and graph databases under the hood. The main benefit is, as the repo even states "Fast data processing: Links traversal is processed with O(1) complexity."

So, technically, you can do deep traversals quicker. A few notes:

1. Few use cases truly need low-latency deep traversal on realtime data (>5 hops). There are some well known ones like fraud detection in payment processing and, possibly, social media recommendation engines. But I am not even sure how latest social media engines work, and whether they still rely on graph DBs.

2. However, in practice the advantage is often marginal. With modern analytical databases, or even an optimized PostgreSQL (ltree, materialized views, pgrouting, pg_duckdb, etc), you often get more than good enough performance. In addition those traditional SQL DBs scale with hardware more easily than graph databases. So, you can always use the lever: "Throw more hardware at it."

3. Even Graph DBs don't get good traversal performance under all conditions without hand tuning. For example, there is the "super node" issue, a node with an abnormally high number of connections (edges). And if you still need hand-tuning, you might as well choose something more versatile.

4. The ecosystem of a PostgreSQL and other popular DBs is just unbeaten. With graph DBs, you often prematurely put yourself in a corner that you don't want to be in.

Hence, my recommendation. Unless you are really sure that a graph DB is the right fit for your use case, start with something else, and go the graph db way when you have established a true need.

I'm a bit of a Forensic Files nerd, so I worked on a little side project a while back to pull the transcripts from several episodes, use entity recognition to categorize people, places, things, etc, and load them into a Neo4j database (via Cypher queries). It turns out there's something called the POLE data model[1] that can be used by law enforcement to help solve crimes. You load all the details into a graph database and evaluate the relationships to aid in solving crimes. I suppose you could argue a criminal investigation is essentially graph traversal.

[1] https://neo4j.com/blog/government/graph-technology-pole-posi...

Edit: typo

I played around with Neo4j and only ever found two domains where it excelled.

- custom app security

- social media

I also think cypher is a brilliant way to query a graph.

I worked for the research branch of a children's hospital. At one point, I was brought into vendor evaluations a department wanted to buy. Their tool had something to do with visualizing protein interactions, which was highly networked. It was basically a Neo4j database with a React UI on top of it.

Neo4j is a great DB but their license price is egregious for enterprise customers. A few years ago I was involved in negotiating a contract for a small/medium size kubernetes deployment (think around 25 cores) and the annual price was more than the salary of a senior SWE full-time equivalent. See this page for an idea of their prices in 2018: https://blog.igovsol.com/2018/01/10/Neo4j-Commercial-Prices....

Didn't Neo4J pivot away from being a boring embedded DB which you point at a path and then traverse through Node objects, and decide to become some kind of paid platform with a client-server protocol and proprietary query DSL?

I remembered it from a uni course (early 10s?) a few years ago for a use-case we didn't end up pursuing, but I wasn't hugely comfortable with investing effort into what I saw.

That's a good question indeed. Also I wonder why they picked java as the implementation language.

It's embedded. Single machine. But it runs their forum/ticketing thing so good enough for that I guess :)

A successor to it, yes: https://medium.com/@youtrackdb/long-road-ahead-6d648141a190

That's funny, one of my buddies from college was one of the OG Versant employees (I assume there's not another OODBMS named Versant). That was in the late 80s.

Yes, POET for C++, for example.

http://www.kevra.org/TheBestOfNext/ThirdPartyProducts/ThirdP...

It was split from youtrack internals, IIRC

current name is smelling tho +1