I wonder if there's a design decision documented somewhere that makes the existing graph databases like Neo4j, etc. not good enough for Youtrack's use case.
That's true, although, if you look at them, you wouldn't notice. The only mention of JVM you can see in the IDEs is in the About dialog, and the IDEs install and run their own OpenJDK, so no JVM has to be installed globally. Almost as if they were a bit self-conscious about using such an "unsexy" architecture...
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....
Also embedding Neo4j is not possible, that seems to be the killer feature for YouTrackDB, they even shade dependencies so it’s like a no deps Java library for your application.
> small/medium size kubernetes deployment (think around 25 cores
That's ~1 machine. 1 SWE for a database isn't egregious, databases provide huge value, but for that little performance, that's crazy.
I can only assume as core count has blown up over the last 10 years, the pricing has somewhat diminished, but still, I'd be expecting a heck of a lot more capacity for 1 SWE.
Not just that, if a database company has both a community edition and enterprise then it’s likely the enterprise will get many new features that the community edition will never get.
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.
I've always been curious about graph DBs and dabbled a bit in them, but for those who have more extensive experience in them-- are they really worth it? Is it that for small scale SQL is better and graph DBs really only matter at scale, or for specific use cases with highly connected data?
I worked in a startup whose value proposition was large 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 or deeper). 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 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.
TIL - YouTrack was first released in 2009, Kotlin in 2011, so I wouldn't call it long before, but definitely before. Guess I'm more interested in programming languages than in task management tools, that's probably why I have been aware of Kotlin longer than of YouTrack...
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.
Object databases routinely go away and routinely come back.
Ten years ago I worked with a database called Versant OODBMS (from Actian). I was a junior sysadmin so i was essentially administering it at a very surface level but skimming the documentation (and trying some of the samples) it was very cool that you could pick essentially any random class, implement an interface (and hence a few method) and that was it, you had a database-serializable object.
The main issue was really scaling out (as in, multiple machines) but otherwise was a really great database.
I played around with something similar before called typedb. It also does object oriented graph model which was a bit weird at first after using sql for a long time, but once it clicks there's a lot of thing that you could express surprisingly nicely
supriyo-biswas | 3 hours ago
zihotki | 3 hours ago
rednb | 3 hours ago
jonathanlydall | 3 hours ago
rob74 | 2 hours ago
mike_hearn | an hour ago
Hendrikto | 13 minutes ago
fsuts | 2 hours ago
It’s JetBrains who were synonymous with Java so not a surprise, if was a recent project would have been Kotlin (which this company created)
winrid | 2 hours ago
pandoro | 3 hours ago
brabel | 3 hours ago
danpalmer | 3 hours ago
That's ~1 machine. 1 SWE for a database isn't egregious, databases provide huge value, but for that little performance, that's crazy.
I can only assume as core count has blown up over the last 10 years, the pricing has somewhat diminished, but still, I'd be expecting a heck of a lot more capacity for 1 SWE.
fsuts | 2 hours ago
Ongoing enshittification risk.
denismi | 3 hours ago
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.
ajhenrydev | 3 hours ago
winrid | 2 hours ago
td2 | 3 hours ago
p_l | 2 hours ago
[OP] gjvc | 3 hours ago
ggcr | 3 hours ago
jacolbj | 2 hours ago
brobdingnagians | 2 hours ago
ChicagoDave | an hour ago
- custom app security
- social media
I also think cypher is a brilliant way to query a graph.
shaism | 41 minutes ago
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 or deeper). 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.
snapetom | 33 minutes ago
rob74 | 2 hours ago
atraac | an hour ago
rob74 | an hour ago
Cthulhu_ | an hour ago
mike_hearn | an hour ago
znpy | an hour ago
Ten years ago I worked with a database called Versant OODBMS (from Actian). I was a junior sysadmin so i was essentially administering it at a very surface level but skimming the documentation (and trying some of the samples) it was very cool that you could pick essentially any random class, implement an interface (and hence a few method) and that was it, you had a database-serializable object.
The main issue was really scaling out (as in, multiple machines) but otherwise was a really great database.
rickette | an hour ago
l337h4x0rz | 29 minutes ago
marcodena | 14 minutes ago