Data Import with Neo4j Aura
In this guide, we will see how Neo4j Aura imports data differently from other Neo4j instances and how to navigate those differences.
Because Neo4j Aura is a database instance that is located and maintained in the cloud, we must take care to ensure data integrity is maintained and access is carefully granted to avoid malicious tampering.
To mediate these risks, Neo4j Aura has increased security and access to database-as-a-service instances. While this means that malicious users cannot harm the data or infiltrate the system, it also means that certain tasks and processes may not work exactly the same as with other local or remote Neo4j databases.
We will cover what those differences are, why they exist, and how to still get the data into the instance.
Let’s go through the differences, one at a time.
Why? Restricting access to internal Neo4j folders avoids non-authorized users from accessing and tampering with the folder and contents. This prevents any user from dropping malicious files into the folder and potentially corrupting the database.
Why? Similar to the import folder accessibility above, disk access has been locked down to avoid malicious activity and data/instance corruption by unauthorized users.
To use this tool, we can still run it locally to import onto a local instance, then push the imported data to cloud by uploading our database.
Why? As with both of the above examples, disk and folder access for internal Neo4j folders has been restricted to avoid malicious activity. This means that the plugins folder is not visible where we cannot drop custom plugin files in as extensions.
The Neo4j ETL tool still operates in a cloud environment, but we will need to use the 1.4.1 release. This release changes the way the ETL tool imports the data. To find out more, check out the article on what changed and how to use it.
As discussed in most of the points above, Neo4j Aura will not access local storage for protection reasons. We can still use APOC to access publicly accessible files or to load secure files. For more information, check out Andrew Jefferson’s blog posts on loading public data and loading secure files into remote instances.
In other types of installations, users could place API credentials in the
neo4j.conf file and reference them in Cypher statements like environment variables.
With Neo4j Aura, however, those internal folders and files have been hidden, so this functionality must be handled in other ways.
Whether we store these credentials in a secure file on the cloud or store them as parameters in Neo4j with Cypher, we must use these best practices to avoid non-authorized users accessing private credentials or information.
Was this page helpful?