61–70 of 73 posts
Earlier quoted context omitted.
Apache AGE seems like a good way to have the battle testedness of Postgres with a more fluent query language. I have only used AGE in smaller projects so far however.
Postgres 19, which is about to be released is adding support for SQL/PGQ.
Worth clicking into .claude/agents/ in this repo. There are 25 agent definitions, 10 of them code-review dimensions.
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, yo…
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.
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?
Most graph databases only offer an advantage in query language, as it allows for more ergonomic graph traversal compared to e.g. recursive CTEs in SQL. However with SQL/PGQ, the same query ergonomics are coming to traditional databases. If you look under the hood there is usually nothing special about graph databases that will make them more performant. If you lay out a query plan side-by side between e.g. Postgres a…
I like how PG19 with PGQ will kill lots of companies and startups.
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.
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....
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?
Most graph databases only offer an advantage in query language, as it allows for more ergonomic graph traversal compared to e.g. recursive CTEs in SQL. However with SQL/PGQ, the same query ergonomics are coming to traditional databases. If you look under the hood there is usually nothing special about graph databases that will make them more performant. If you lay out a query plan side-by side between e.g. Postgres a…
Response: https://blog.ladybugdb.com/post/better-graph-database-ball/
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?
Graph query languages like Cypher are great, but I am wholly unconvinced by the concept of a dedicated, general-purpose "graph database". IMO, you're better off just using Postgres/etc, modeling your graph data there, and pulling in subsets of your graph for in-memory analysis. This is for the 99% of enterprises that aren't doing online streaming graph analysis on TB-scale graphs, and the other 1% should probably fig…
* Columnar storage * Compressed Sparse Row on disk * Factorized joins * ASP joins, WCO Joins
Details: https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...
Earlier quoted context omitted.
Bundling a JDK with the app is the officially sanctioned way to ship Java apps since Java 9, so for over a decade now.
You mean a JRE, because the whole JDK contains a bunch of things you're never going to need. Mind you, a default JRE redistribution makes your app at least 100+MB. Using jdeps to strip out unneeded things is a good idea if you want it to get down to 25 ish MBs.
Earlier quoted context omitted.
Graph query languages like Cypher are great, but I am wholly unconvinced by the concept of a dedicated, general-purpose "graph database". IMO, you're better off just using Postgres/etc, modeling your graph data there, and pulling in subsets of your graph for in-memory analysis. This is for the 99% of enterprises that aren't doing online streaming graph analysis on TB-scale graphs, and the other 1% should probably fig…
We had general-purpose graph databases before graph databases became a thing. I'm talking about relational databases. Values are the vertices, tuples are the edges, FK constraints are inclusion dependencies. In fact, n-ary relations means a hypergraph database, not just a binary graph db.
The main innovation is the "REL table". You can think of it as a many-to-many relationship table on steroids with optimizations at the storage layer and join algorithms.
Definition of what makes something a graph database (apart from the query language) is contested. But we seem to be moving towards: build a reasonable relational database and then add a "REL table" to it with join optimizations.