Switch to AgensGraph for right-now access to both relational and graph data
Among many of the mind-blowing strengths, AgensGraph provides to the field, no one can miss its super-flexibility and easiness of dealing with relational tables. As a bare child of PostgreSQL, AgensGraph requires nothing when a user wishes to access and query rows from existing tables in PostgreSQL side; just type SQL in your client interface as you always did in your PostgreSQL environment, and type Cypher too to use that result for creating or modifying graph.
One most simplified example that shows AgensGraph’s unparalleled usability would be like:
|LOAD FROM names AS persons
REATE (:Person = persons);
‘names’ is a relational table with default schema in PostgreSQL side of AgensGraph and here we used LOAD FROM clause to access ‘names’ table with an alias called ‘persons.’ Then, every single value in this table is inside the scope of graph creating, modifying and querying task.
This is much simpler and quicker access to relational data than our major competitors in the graph database domain because graph data and PostgreSQL tables are in the same visible space in AgensGraph. (And this is why we call our product “multi-model” and offer hybrid querying: SQL on Cypher statement and vice versa)
So if your business or project is relying on PostgreSQL and have to adopt/convert to graph structure for higher level tasks, just walk away from your computer, have a cup of tea and relax because you are destined to have more time except this leave, for not engaging with any bit of ETL process and considerations for migration, once you have chosen AgensGraph as your database, of course.
In other words, for anyone who belongs to PostgreSQL side and implements AgensGraph to use graph data, there is NO MIGRATION TASK of relational table, no configuration & set up, no third-party tool, no scripts, no commands, no nothing.
The power of sharing the same scope of objects for both graph and relational data is maximized when you dock with our hybrid querying:
— Simple Hybrid Querying Examples from IMDB movie data
— SQL on Cypher
Explaining the amazing capabilities of AgensGraph’s hybrid querying easily runs off the limit of this posting. Instead, we’d like to introduce a small comparison between AgensGraph and one of our major competitors in terms of the migration of relational data.
|Migration Methods for PostgreSQL||Table → CSV → Neo4j||(W)RIGHT QUERY,
|ETL related utility (batch-importer, groovy)|
|Client Driver (JDBC, etc.)|
Of course, AgensGraph officially supports client drivers for Python & JDBC. Or, you can also use Node.js and GoLang drivers (unofficially supported).
Other benefits that AgensGraph users can enjoy is that it brings the most from what PostgreSQL can offer; supports XML, a list of OS (FreeBSD / HP-UX / Linux / NetBSD / OpenBSD / OS X / Solaris / Unix / Windows), and data connector for “Hadoop” (one of PostgreSQL extensions called haddop_fdw) which is why AgensGraph will rule over the future of big data by integrating large volume unstructured data into graph environment.
Likewise, AgensGraph users in PostgreSQL side can experience seamless usability ━ as the perfect migration is no migration ━ and concentrate on more meaningful tasks, empowering graph analysis and value discovery at peak efficiency always.
So far, we’ve introduced AgensGraph, the GDBMS that allows users to access PostgreSQL relational and graph data without any effort.
You can use AgensGraph by visiting the Bitnine website.
Please contact firstname.lastname@example.org with any questions or inquiries regarding AgensGraph. Your questions will be answered promptly.