
Agens Graph – PostgreSQL Based Graph Database - aeontech
http://www.agensgraph.com/
======
justinclift
Heh Heh Heh

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/](https://www.postgresql.org/about/history/)

~~~
pygy_
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](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.

~~~
justinclift
Yeah, I wondered if anyone was going to be pedantic about that. ;)

~~~
jlg23
"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.

~~~
derefr
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.

~~~
pgaddict
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.

~~~
justinclift
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. ;)

~~~
dorcus_maximus
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.

------
danielmorozoff
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.

------
faizshah
Here's slides from a recent talk on it:
[https://www.percona.com/live/17/sites/default/files/slides/A...](https://www.percona.com/live/17/sites/default/files/slides/AgensGraph.PerconaLive.2017.pptx_.pdf)

------
jarym
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:(

~~~
pgaddict
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.

------
moron4hire
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.

~~~
eternalban
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.)

~~~
ci5er
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.

------
aeontech
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.

~~~
lauretas
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).

~~~
Dnguyen
There's also
[https://github.com/postgraphql/postgraphql](https://github.com/postgraphql/postgraphql)

~~~
purple-dragon
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.

------
bfrog
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.

------
crudbug
Interesting .. is the team considering Gremlin support as well .. It is sort
Of a standard with Graph DBs

