Agens Graph – PostgreSQL Based Graph Database(agensgraph.com)
agensgraph.com
Agens Graph – PostgreSQL Based Graph Database
http://www.agensgraph.com/
46 comments
NoSQL refers to non-relational DBMSes, not a literal lack of SQL... QUEL is, if anything, closer to relational algebra than SQL is.
https://en.wikipedia.org/wiki/QUEL_query_languages
QUEL is a better language (more consistent), and SQL won not on technical grounds, but because Larry Ellison is a better salesman than Michael Stonebraker.
https://en.wikipedia.org/wiki/QUEL_query_languages
QUEL is a better language (more consistent), and SQL won not on technical grounds, but because Larry Ellison is a better salesman than Michael Stonebraker.
Yeah, I wondered if anyone was going to be pedantic about that. ;)
"Pedantic"?
Your post is wholly based on time travel (~"nosql predates sql") and introduces a completely alternative evolution of database design in which quel never happened and we go "full circle" to the nosql-that-was-prior-to-sql.
Your post is wholly based on time travel (~"nosql predates sql") and introduces a completely alternative evolution of database design in which quel never happened and we go "full circle" to the nosql-that-was-prior-to-sql.
I don't think the parent claimed that NoSQL existed at the time; just that Postgres was a NoSQL database as we understand the term today. Like describing a wandering swordsman in ancient China as a "knight-errant", even if knights themselves as legally-warranted weapon-carriers didn't yet exist.
Which is not to say that the poster wasn't wrong about their claim, but it's not invalid to make said claim in casual English in the particular way you're implying.
Though, also, in the more general case, "NoSQL" databases did certainly exist at the time Postgres was conceived (Postgres just wasn't one of them.) Navigational databases like IBM IMS were what we'd call "a NoSQL database" if they were conceived today.
Which is not to say that the poster wasn't wrong about their claim, but it's not invalid to make said claim in casual English in the particular way you're implying.
Though, also, in the more general case, "NoSQL" databases did certainly exist at the time Postgres was conceived (Postgres just wasn't one of them.) Navigational databases like IBM IMS were what we'd call "a NoSQL database" if they were conceived today.
I don't think Postgres was "NoSQL database as we understand the term today". The basis of NoSQL is not the lack of SQL but the non-relational data model. Postgres (mostly) sticks to the relational data model, although it performs surprisingly well when used as a NoSQL data store.
Well, I definitely meant it as "the lack of SQL" when I wrote above. Didn't realise people would actually give a crap to the point they have though. ;)
Then it is a case of what you meant and what you said being different things. So, yeah, people give a crap when something is confusing or incorrect. I mean, we write code, right? Being correct matters. NoSQL means it is something other than a relational database.
Thank God you haven't claimed it was webscale. We'd get nuts.
That's not being pedantic
Can someone speak to how Agens compares to Neo4j? Since from a quick glance they seem to be using some of Neo's features.
I'd be interested in seeing performance comparisons as it seems Agens is implemented in C.
I'd be interested in seeing performance comparisons as it seems Agens is implemented in C.
Here's slides from a recent talk on it: https://www.percona.com/live/17/sites/default/files/slides/A...
I've been following this for a few months.
It looks neat but too new to entrust to any major project in my opinion. Also seems too new to put together and meaningful performance comparison since it still seems they're finding frequent improvements.
I really wished this could have been distributed as an extension rather than a totally separate Postgres package. It is much easier to play with extensions... I read somewhere they can't do it since they have to modify non-extensible bits of code:(
It looks neat but too new to entrust to any major project in my opinion. Also seems too new to put together and meaningful performance comparison since it still seems they're finding frequent improvements.
I really wished this could have been distributed as an extension rather than a totally separate Postgres package. It is much easier to play with extensions... I read somewhere they can't do it since they have to modify non-extensible bits of code:(
Everything is "too new" at some point, and matures over time.
But I don't know why a performance comparison would not be meaningful at this point? I mean, it may get obsolete soon, but it's the only way to guide optimizations efforts - you do a test, decide what makes most sense to improve (cost/benefit) and then you fix it. Then you do the test again.
I'm sure Bitnine developers do such benchmarks as part of development, but perhaps they decided not to publish that at this point. That's perfectly understandable - development benchmarks are one thing, but publishing the results requires much more care. Particularly when it's a comparison with other products.
But hey, there's nothing simpler than doing a quick benchmark on your own - after all, the best benchmark is one modeling your particular use case.
But I don't know why a performance comparison would not be meaningful at this point? I mean, it may get obsolete soon, but it's the only way to guide optimizations efforts - you do a test, decide what makes most sense to improve (cost/benefit) and then you fix it. Then you do the test again.
I'm sure Bitnine developers do such benchmarks as part of development, but perhaps they decided not to publish that at this point. That's perfectly understandable - development benchmarks are one thing, but publishing the results requires much more care. Particularly when it's a comparison with other products.
But hey, there's nothing simpler than doing a quick benchmark on your own - after all, the best benchmark is one modeling your particular use case.
This is awesome. So many of the problems in legacy projects that I've had to deal with have been from trying to shoehorn a graph business process into a tree database.
A "graph business process" is borderline content free. All business processes can be expressed by graphs. What is a graph? A dynamic data structure. That is it.
So what is a "tree database"? A graph database with a bias for a specific ordering of its nodes. Does that make a tree database a query result (path traversal) in a graph database? The confusion of it all.
So imho one uses a "graph database" when (a) the domain is open ended, and (b) information is sketchy (precisely: incomplete), and as an important case in an open ended domain (c) we need to express a set of relationship types and ordering.
Semantic systems, for example, fit that description and can be reasonably considered as /fundamentally/ graph based. Some CRUD backend and OLAP on that domain likely does not.
To conclude, the naive impulse to reach for a graph db is likely induced by a recognition for needing something more expressive than a k/v, or doc store with secondary indexes, but fearing the dreaded RDBMS. Thus one "shoehorns" a static, completely captured, and fully described, domain unto a graph database cause E-R ain't sexy and SQL is a mystery. (Heads up: graph path expressions can get hairy too.)
So what is a "tree database"? A graph database with a bias for a specific ordering of its nodes. Does that make a tree database a query result (path traversal) in a graph database? The confusion of it all.
So imho one uses a "graph database" when (a) the domain is open ended, and (b) information is sketchy (precisely: incomplete), and as an important case in an open ended domain (c) we need to express a set of relationship types and ordering.
Semantic systems, for example, fit that description and can be reasonably considered as /fundamentally/ graph based. Some CRUD backend and OLAP on that domain likely does not.
To conclude, the naive impulse to reach for a graph db is likely induced by a recognition for needing something more expressive than a k/v, or doc store with secondary indexes, but fearing the dreaded RDBMS. Thus one "shoehorns" a static, completely captured, and fully described, domain unto a graph database cause E-R ain't sexy and SQL is a mystery. (Heads up: graph path expressions can get hairy too.)
I'm a fan of RDBMS (E-R) and SQL - it's cute and all for things like purchase orders and shopping carts and orders and receipts and the like. But for things like clinical informatics (even the non-semantic kind), graph traversal is easier than the unholy join from hell. For example.
You seem to know a hell of a lot about me and my particular problems from one, simple message. Tell me, oh great and powerful wizard, how does one acquire such awesome powers of wild-ass, baseless extrapolation?
Wondering if anyone has experience with it... there's a lot of competition in graph database market, curious to see if this is worth investing time in.
There isn't a lot of competition in the "free/libre database" market though. The only serious players are Jena/Fuseki (an RDF store) and Janus (a graph store).
There is also Cayley (https://github.com/cayleygraph/cayley) which supports more query languages, including GraphQL, and multiple backend stores.
There's also https://github.com/postgraphql/postgraphql
PostgraphQL generates a GraphQL API from a PostgreSQL database. It won't change how your data is modeled or queried at the database level, i.e., it is NOT a graph database project like Agens, Neo4j, Cayley, etc.
This isn't a graph database, it's GraphQL which is an (unfortunately named) interface or "language" to query data, regardless of what the underlying database or data model is.
I can vouch for this one. I've been building apps with PostGraphQL for about a year and love it. The dev community around that project is strong.
I've been watching https://dgraph.io with great interest. Looks like it could become a very solid contender as a horizontally scalable open source graph database engine.
Dgraph seems to be the most promising along with http://janusgraph.org/ for scalable graphs.
Oh? Neo4j is free. The Community edition is GPLv3, and the Enterprise edition is AGPLv3.
The Enterprise Edition is not AGPL. It's under one of "Neo4j Commercial License", "Neo4j Evaluation License", "Neo4j Educational License", or "Fair Trade Licensing". In other words it's not free.
Why would I want to use the "Community Edition" of a company whose interest is to force me into buying their Enterprise Edition? The more people use this "Community Edition", and the more they are encouraged to force their "Enterprise Edition" under my throat, because "it will be easier to buy a proprietary plugin than change database". They are already restricting the use of important features such as "Unlimited graph size", "Database storage reallocation", "Schema constraints", "Runtime to accelerate common queries", "Role-based security", "Kerberos Security", "Load balancing", etc. Why would I want to get into this?! I'd rather spend my time learning and contributing to Jena or Janus than a bait "Community Edition".
The "enterprise edition" is AGPL. Feel free to interpret it differently then Neo does, but the license is AGPL [1]. Anyways, I don't understand the hostility. They're tying to walk the line between a profitable company selling software while still doing it all in the open. The fact that they kept things open source and not closed was one of the things I loved about working there.
1. https://github.com/neo4j/neo4j/blob/3.3/README.asciidoc
1. https://github.com/neo4j/neo4j/blob/3.3/README.asciidoc
So, are you saying that Neo4j is 100% free as in "100% AGPL, otherwise Commercial License if you don't want to use the AGPL"? In other words, the code is exactly the same, only with a different license?
Yes, that is the case.
According to [this page](https://neo4j.com/editions/) it's not. In fact, they are restricting important functionalities to their Enterprise Edition exclusively. Which means, the codebase is not the same.
Yes, the Community Edition and the Enterprise Edition are different. Certain functionality is restricted to the Enterprise Edition. It's a different codebase. I didn't say otherwise.
You can see it here: http://github.com/neo4j/neo4j
See how there are 'community' and 'enterprise' top-level directories? The 'enterprise' directory contains the enterprise-specific code. It's a separate project in some senses but it does share the same repository, and it is open source.
As you can also see by looking at that repository, the Enterprise Edition is licensed as AGPL. Here is the license: https://github.com/neo4j/neo4j/blob/3.3/enterprise/LICENSE.t...
I'll quote:
You can see it here: http://github.com/neo4j/neo4j
See how there are 'community' and 'enterprise' top-level directories? The 'enterprise' directory contains the enterprise-specific code. It's a separate project in some senses but it does share the same repository, and it is open source.
As you can also see by looking at that repository, the Enterprise Edition is licensed as AGPL. Here is the license: https://github.com/neo4j/neo4j/blob/3.3/enterprise/LICENSE.t...
I'll quote:
If you have not executed a Commercial Agreement with Neo Technology, the
Software is subject to the terms of the GNU AFFERO
GENERAL PUBLIC LICENSE
Version 3, as follows:
It is AGPL; it's dual licensed. You can use it freely under the terms of AGPL, or you can enter into a commercial agreement with Neo Technology and use it without the restrictions imposed by the AGPL.
Here's the license: https://github.com/neo4j/neo4j/blob/3.3/enterprise/LICENSE.t...
Here's the license: https://github.com/neo4j/neo4j/blob/3.3/enterprise/LICENSE.t...
There's nothing wrong with companies charging for software products.
I agree. This is not the point though, nor what I said.
It reminded me http://grakn.ai , another quite solid and interesting project right know.
Well some of the competitions regardless of free or commerical are built using either a known NoSQL or a known relational database as the backend.
Postgres having recursive CTE's made graph querying with SQL actually pretty tenable. I designed a graph like schema for a company I worked at awhile ago now with postgres and recursive CTE's in mind. Worked relatively well though some queries were quite large.
Interesting .. is the team considering Gremlin support as well .. It is sort Of a standard with Graph DBs
Back in the early days PostgreSQL was a NoSQL database called Postgres, using a query language called POSTQUEL.
Then SQL was added, becoming PostgreSQL.
With Agens Graph adding an optional non-SQL query language back to it, it seems like it's gone a full circle. Hopefully on an upward slope though. :)
If anyone's interested in the pre-SQL Postgres, there's some info here: https://www.postgresql.org/about/history/