Introducing Neo4j 4.1

Six months ago we proudly released Neo4j 4.0 – by far the most innovative, secure and scalable graph database on the planet.

Today, we are proud to announce the new version of our graph database product: Neo4j 4.1.

As many could expect, with the release of Neo4j 4.0, we introduced architectural changes. In Neo4j 4.1, we have extended existing 4.0 features while adding extra functionality that makes Neo4j even more secure and robust for your mission-critical applications.

Let’s have a look at a few exciting additions to Neo4j 4.1.

Role-Based Access Control and Granular Security

In Neo4j 4.0, we introduced Role-Based Access Control (RBAC) security, a fine-grained level of control and authorization that is unavailable in any other graph database.

The main focus of Neo4j 4.0 was the ability to control access of data for reading. This functionality added the power to define roles (and associate roles to users) that control the access of individual objects to be accessed, read or traversed.

In Neo4j 4.1, we have extended this granularity to all write operations. Now you can set roles with grants that allow you to create, replace and delete objects; or add, remove or modify properties of those objects. Neo4j 4.1 allows you to create roles that have administrative access to the database without any access to the data.

For example, you can set roles that do not have access to the user data but may apply changes at the administrator level to users, roles and the data model. You can also create “Operator” users who are allowed to create new users, create and associate new databases, change passwords and permissions, but they do not have access to the users’ data.

What’s Now Possible with Granular Security

Think of a hospital with a medical records application that has a variety of people who need different levels of access: doctors, patients, customer service representatives and IT admins. Doctors need to access and change all the data and information on all of their patients. Patients need to be able to access (read) their information, but they can’t change all of their medical data. Customer service representatives need to access a small portion of the patient data to get contact information without seeing sensitive patient health data. And finally, IT admins may not need access to the data but need to be able to set user permissions and reset passwords.

The enhanced granular security features of Neo4j 4.1 accommodate all of these scenarios. The doctor has full read and write access, while the patients and customer service representatives can only access/read certain parts of the graph.

The improvement to database administration in 4.1 allows for the IT administrator to be an Operator for more granular control of the application – meaning they can create users and define roles without ever seeing the data. The administrator can also change passwords and settings while maintaining the tight security parameter of a hospital.

This new feature is key for organizations using Neo4j to build SaaS applications. Administrators can create and manage databases without accessing or seeing their customer data or information. Also SaaS providers can grant administrators access to change passwords and usernames for their particular departments or applications.

Neo4j Causal Clustering

There are two big news items on the Causal Clustering front: Leader Transfer Extensions and Embedded Causal Clustering.

Until Neo4j 3.5, developers who embedded Neo4j in their applications could use the Highly Available (HA) cluster. HA cluster is based on a primary + secondary + arbitrator architecture where transactions are propagated from the primary instance to one or more secondary instances. HA Cluster was deprecated in Neo4j 3.5 and it is not available in Neo4j 4.X.

Lead Transfer Extension

Another important addition to Neo4j 4.1 is the Leader Transfer Extension. Causal Clustering is based on an architecture that automatically handles leader election and transfer among members of a cluster. There are situations where such elections should be triggered to organize or reorganize the cluster.

Let’s consider, for example, a cluster with a relatively large number of databases. In Neo4j 4.1, we can balance the leadership for databases among all the members of a cluster and evenly distribute read and write workloads.



Another interesting use case is the handling of cluster members across multiple data centers. We may want to maintain leadership in one data center and transfer leadership to members in the other data center only when there are no other options available.

Neo4j Embedded Mode Now Supports Causal Clustering

In Neo4j 4.1, we included Causal Clustering for customers who developed applications with Embedded Neo4j. In simple terms, this means developers can embed a clustered version of Neo4j that is highly available and scalable through Causal Clustering.

Applications must be able to identify leaders and followers in a cluster in order to direct or redirect transactions locally or to other members of the cluster. Now developers can add the performance provided by Neo4j native graph architecture as well as the scalability and availability of the Causal Cluster architecture – an improvement over the second-generation “HA” architecture it replaces.

Query Planner

Two simple but impactful changes have occurred in the query planner.

In Neo4j 4.1, you can control the replanning of queries, overriding the default handling thresholds for automatic replanning. You can also force a pre-cache replanning – or skip replanning altogether – even when the general rules would require it.

We have also improved the output of the Cypher query plan. The query plan now provides information on returned rows and hits, but also memory usage, correlation with internal and user-defined variables, among other details.

This additional insight about what the database is doing under the hood, together with the added knobs to fine-tune replanning behavior, makes it easier to fine-tune query performance and keep applications humming.

Memory Management

In Neo4j 4.1, we have also added new tools to control the use of the internal memory on a per-transaction basis. We have added memory estimations for query and transaction operations, and we compare them against thresholds that can be set for a transaction, a database or the whole DBMS.

The objective is to control memory-hungry transactions that may affect the performance of the whole system.

Memory management is beneficial when there are multiple users or multiple databases running concurrent memory-hungry queries, especially when running in memory-constrained environments. It will also help with stability of large HTAP clusters (those that combine transactional and analytic processing), because of the impact that overly memory-hungry queries can have on clusters in the absence of transaction-based memory controls.

One example would be a large bank with multiple Neo4j databases running in a single instance with different use cases, such as fraud, risk and HR. With memory management, users can now help to control the large memory transactions so the entire DBMS memory doesn’t get consumed by one large fraud use case.

Putting It All Together

If you want to try Neo4j 4.1 with a fresh installation, download your favorite package (available on Linux, Windows, MacOS or Docker) from here.

Existing installations of Neo4j 4.0 can be automatically upgraded by using the normal procedures offered by the OS, or by simply copying the existing data over the new version. For cluster environments, you can upgrade any existing Neo4j 4.0 version without downtime using the rolling upgrade functionality.

Once Neo4j 4.1 is up and running, you can point your 4.0-based applications to the new version of the server. The five supported environments – Java, JavaScript, .NET, Python and GO – have 4.0 or 4.1 drivers that are compatible with Neo4j 4.1 (the GO driver is versioned 1.8, and the release ID will be updated soon).

Conclusion

Neo4j 4.1 is a great extension to Neo4j’s mighty 4.0 release that allows you to build faster, scale bigger, be more secure and launch easier. With Neo4j 4.1, administrators have more role-based access control with both reads and writes. Additionally, there are a variety of improvements to Causal Clustering, query planning and memory management.

Since these are not all of the feature releases in 4.1, we encourage you to download the product and try it out. Play with it, test it and feel free to give us your feedback.
//Download Neo4j 4.1