Configuring Neo4j Single Sign-On (SSO)
Enterprise Edition

Neo4j supports SSO authentication and authorization through identity providers implementing the OpenID Connect (OIDC) standard. This page features detailed examples of how to configure Single Sign-On (SSO) for several identity providers. It also presents frequently asked questions and solutions to common problems encountered when configuring SSO.

The following configurations are crafted for a Neo4j Browser served on http://localhost:7474/ (the default URL when starting the database on localhost).

Therefore, when reproducing them in the identity providers, you must modify the redirect URI to include the URI serving your Neo4j Browser application. For example:

http://localhost:7474/browser/?idp_id=<provider>&auth_flow_step=redirect_uri

SSO works in the following way:

  1. The server (Neo4j DBMS) contacts the identity provider (Okta, Entra ID, Google, etc.) and fetches the JSON Web Keys (JWKs) from the provider.

  2. The client (e.g., Bloom, Neo4j Browser, etc.) asks the user for credentials and contacts the identity provider.

  3. The identity provider responds with a JSON Web Token (JWT), a JSON file containing fields (claims) relative to the user (email, audience, groups, etc.).

  4. The client provides the server with the JWT, and the server verifies its signature with the JWKs.

  5. Optionally, you can control the authentication and authorization on a user level by setting dbms.security.require_local_user to true in the neo4j.conf file and the auth providers for the users, which authentication and authorization you want to control, using Cypher. This setting mandates that users with the relevant auth provider attached to them must exist in the database before they can authenticate and authorize with that auth provider. For information on how to modify or create users in this mode, see Manage users.
    This mode allows you the following using Cypher:

    1. Suspend SSO users.

    2. Set a home database for an SSO user.

    3. Set a user-friendly name for an SSO user (rather than relying on the external identifier).

    4. Set a password for an SSO user.

    5. Set a password change requirement for an SSO user.

For further information and examples, see Configure SSO at the user level using auth providers.

JWTs must always contain a value for sub even when using a different claim for username. It is the only claim guaranteed to be unique and stable. Other claims, such as email or preferred_username are less secure and may change over time. They should not be used for authentication. Neo4j may assign permissions to a user based on this username value in a hybrid authorization configuration. Thus, changing the username claim from sub is not recommended.

Okta

The following examples show how to configure Okta for authentication and authorization using access tokens and ID tokens. It assumes that you are using Okta Developer Edition Service. For the complete guide on how to customize tokens returned from Okta with a groups claim, see the Okta official documentation.

Configure the client

  1. From the left-hand side of the Okta dashboard, navigate to Applications and click Create App Integration.

  2. Select OIDC - OpenID Connect for Sign-in method and Single-Page Application for Application type. Because Neo4j Browser is a single-page application, this is the recommended configuration.

  3. Click Next.

  4. Configure the client with the appropriate redirect URI.

    1. Add a name for the app integration.

    2. Add the Sign-in redirect URIs, for example, http://localhost:7474/browser/?idp_id=okta&auth_flow_step=redirect_uri. This URI will accept returned token responses after successful authentication.

  5. Add the Sign-out redirect URIs, for example, http://localhost:7474/.

  6. In the Assignments section, select Skip group assignment for now.

  7. Click Save.

  8. Take note of the Client ID. You will need it later when configuring the Okta parameters and the Well-known OpenID Connect endpoint in the neo4j.conf file.

Assign Okta groups to the application

  1. From the left-hand side of the Okta dashboard, navigate to Dashboard → Directory → Groups, and click Add Group.

  2. Add a name for the group, for example, engineers, and click Save.

  3. Click the group you just created and then click Assign people.

  4. Add users to the group. Users can be added to a group either on user creation or by editing the group.

  5. Assign the group to an application.

    1. Click Applications and then Assign Applications.

    2. Select the application you created earlier and click Assign.

Access token

This example shows how to configure Okta for authentication and authorization using access tokens and how to configure Neo4j to use them.

Add a groups claim to access tokens

  1. From the left-hand side of the Okta dashboard, navigate to Security → API.

  2. Click the default authorization server (the one that shows api://default as audience) to return the groups claim in access tokens:

    1. On the Claims tab, click Add Claim.

    2. Add a claim with the name groups.

    3. From the Value type dropdown, select Groups.

    4. From the Filter dropdown, select Matches regex and the value .*.

    5. Click Create.

Configure Neo4j

  1. Configure Neo4j to use Okta authentication by configuring the following settings in the neo4j.conf file:

    dbms.security.authentication_providers=oidc-okta
dbms.security.authorization_providers=oidc-okta
dbms.security.oidc.okta.display_name=Okta
dbms.security.oidc.okta.auth_flow=pkce
dbms.security.oidc.okta.well_known_discovery_uri=https://example.okta.com/oauth2/default/.well-known/openid-configuration
dbms.security.oidc.okta.audience=api://default
dbms.security.oidc.okta.claims.username=sub
dbms.security.oidc.okta.claims.groups=groups
dbms.security.oidc.okta.params=client_id=0oao2rybx5hIERt5W5d7;response_type=code;scope=openid profile email
dbms.security.oidc.okta.authorization.group_to_role_mapping= "engineers" = admin; \
                                                             "collaborators" = reader

    The token_type_principal and the token_type_authentication are omitted, meaning access tokens are used instead.

    Always use pkce auth flow. It adds an additional layer of security to the authorization code flow, which prevents certain types of attacks, such as authorization code interception attacks.

    implicit flow has been removed from OAuth 2.1 because it exposes the access token in the browser history and the redirect URL, in addition to other security vulnerabilities. Starting with Neo4j 2026.06, its support is deprecated and will be removed in a future release.

  2. Log in with your Okta SSO credentials using the email of an engineer role user that results in an admin role in the database:

    oidc okta successful login
    Figure 1. Okta OIDC successful login

ID token

This example shows how to configure Okta for authentication and authorization using ID tokens and the how to configure Neo4j to use them.

Add a groups claim to ID tokens

You can add a groups claim to ID tokens to configure authentication and authorization using ID tokens.

  1. From the left-hand side of the Okta dashboard, navigate to Security → API.

  2. Click the default authorization server (the one that shows api://default as audience) to return the groups claim in access tokens:

    1. On the Claims tab, click Add Claim.

    2. Add a claim with the name groups.

    3. From the Include in token type dropdown, select ID Token.

    4. From the Value type dropdown, select Groups.

    5. From the Filter dropdown, select Matches regex and the value .*.

    6. Click Create.

  3. Add a claim with the name userid and the value type User ID.

    The userid claim is not included in the ID token by default like the default sub claim for access tokens, thus you need to add it manually. The name you give to your claim needs to be also indicated in the configuration dbms.security.oidc.okta.claims.username=userid in the neo4j.conf file.

    1. Click Add Claim.

    2. Add a claim with the name userid.

    3. From the Include in token type dropdown, select ID Token.

    4. From the Value type dropdown, select Expression.

    5. In the Value field, type (appuser !=null) ? appuser.userName : app.clientId.

    6. Click Create.

Configure Neo4j

  1. Configure Neo4j to use Okta authentication by configuring the following settings in the neo4j.conf file:

    dbms.security.authentication_providers=oidc-okta, native
dbms.security.authorization_providers=oidc-okta
dbms.security.oidc.okta.display_name=Okta
dbms.security.oidc.okta.auth_flow=pkce
dbms.security.oidc.okta.well_known_discovery_uri=https://example.okta.com/oauth2/default/.well-known/openid-configuration
dbms.security.oidc.okta.audience=0oao2rybx5hIERt5W5d7
dbms.security.oidc.okta.claims.username=userid
dbms.security.oidc.okta.claims.groups=groups
dbms.security.oidc.okta.params=client_id=0oao2rybx5hIERt5W5d7;response_type=code;scope=openid profile email
dbms.security.oidc.okta.authorization.group_to_role_mapping="admin_group" = admin;
dbms.security.oidc.okta.config=token_type_principal=id_token;token_type_authentication=id_token

    You can find the audience parameter under OpenID Connect ID Token of your application on the Sign On tab.

    Always use pkce auth flow. It adds an additional layer of security to the authorization code flow, which prevents certain types of attacks, such as authorization code interception attacks.

    implicit flow has been removed from OAuth 2.1 because it exposes the ID token in the browser history and the redirect URL, in addition to other security vulnerabilities. Starting with Neo4j 2026.06, its support is deprecated and will be removed in a future release.

  2. (Optional) If you want control the authentication and authorization on a user level, configure dbms.security.require_local_user to true in the neo4j.conf file. This setting mandates that users with the relevant auth provider attached to them must exist in the database before they can authenticate and authorize with that auth provider. For information on how to create users in this mode, see Creating users.

    For example, to create the user jake who can authenticate using native or okta, and authorize using Okta (as configured in step 3), you can use the following Cypher query:

    CREATE USER jake
SET HOME DATABASE 'jakesHomeDb'
SET AUTH 'oidc-okta' {SET ID 'jakesUniqueOktaUserId'} // `jakesUniqueOktaUserId` must match the value of the claim that you configured via dbms.security.oidc.okta.claims.username
SET AUTH 'native' {SET PASSWORD 'changeme' SET PASSWORD CHANGE REQUIRED}

    See Configure SSO at the user level using auth providers for further examples.

Microsoft Entra ID (formerly Azure Active Directory)

The following examples show how to configure Microsoft Entra ID for authentication and authorization using access tokens and ID tokens.

Register the application

  1. Log in to the Azure portal.

  2. Click Microsoft Entra ID and navigate to Manage → App registrations.

  3. Click New registration.

  4. Type a name for your application, for example, Neo4j SSO.

  5. Under Select the supported account types, select Accounts in this organizational directory only (Default Directory only - Single tenant) or the option appropriate for your deployment.

  6. Under Redirect URI, select Single-page application (SPA) and enter the following static redirect URI: http://localhost:7474/browser/?idp_id=azure&auth_flow_step=redirect_uri. This redirect URI is supported only by single-tenant applications and is used to redirect the user back to the Neo4j Browser after successful authentication.

  7. Click Register.

Access token

This example shows how to configure Neo4j to use an Entra ID access token for authentication and authorization.

Configure Entra ID

  1. From the App registrations page, select the app you just created.

  2. From the left-hand side menu, navigate to Manage → Token configuration.

    1. Click Add groups claim.

    2. Select Groups assigned to the application (recommended for large enterprise companies to avoid exceeding the limit on the number of groups a token can emit) to include in your access token.

    3. Save your changes.

  3. Navigate to Expose an API and click Add a Scope.

    The first time you click the Add a Scope button, you see a new pane stating that you need to add an Application ID URI before proceeding. You can find it on your app Overview page. It is a GUID that looks like this: api://<GUID>. The GUID is a unique identifier for your application.

  4. Click Save and continue after setting the Application ID URI.

  5. Fill in all mandatory fields in the pane Add a scope.

    1. Enter a new Scope name (e.g., access-token), Admin consent display name, and Admin consent description.

    2. Make sure the Enabled scope state is selected.

    3. Select the Add scope button again to create a new scope. You can add all scopes supported by your API. Make a note of them for later.

Configure Neo4j

You can configure Neo4j to use Entra ID for authentication by configuring the following settings in the neo4j.conf file:

# Configure the access_token
dbms.security.oidc.azure.config=principal=sub;code_challenge_method=S256;token_type_principal=access_token;token_type_authentication=access_token
# Configure the OIDC token endpoint with the Directory (tenant) ID
dbms.security.oidc.azure.token_endpoint=https://login.microsoftonline.com/54e85725-ed2a-49a4-a19e-11c8d29f9a0f/oauth2/v2.0/token
# Configure the iss claim in the access token with the Directory (tenant) ID
dbms.security.oidc.azure.issuer=https://login.microsoftonline.com/54e85725-ed2a-49a4-a19e-11c8d29f9a0f/v2.0
# Configure the audience claim in the access token with the Application (client) ID
dbms.security.oidc.azure.audience=4376dc8b-b5af-424f-9ada-c1c1b2d416b9
# Configure the OIDC well-known discovery endpoint with the Directory (tenant) ID
dbms.security.oidc.azure.well_known_discovery_uri=https://login.microsoftonline.com/54e85725-ed2a-49a4-a19e-11c8d29f9a0f/v2.0/.well-known/openid-configuration
# Make sure you add the trailing slash (`/`) at the end of the URL or this operation might fail.
dbms.security.oidc.azure.issuer=https://login.microsoftonline.com/54e85725-ed2a-49a4-a19e-11c8d29f9a0f/v2.0
# Provide the Entra ID parameters, such as client_id, response_type, scope, etc.
dbms.security.oidc.azure.params=client_id=4376dc8b-b5af-424f-9ada-c1c1b2d416b9;response_type=code;scope=openid profile email api://4376dc8b-b5af-424f-9ada-c1c1b2d416b9/access-token

ID token

This example shows how to configure Neo4j to use an Entra ID ID token for authentication and authorization.

Configure Neo4j

  1. From the App registrations page, select the app you created in Register the application.

  2. On the application Overview page, copy the Application (client) ID value and use it to configure the following properties in the neo4j.conf file:

    dbms.security.oidc.azure.audience=4376dc8b-b5af-424f-9ada-c1c1b2d416b9
dbms.security.oidc.azure.params=client_id=4376dc8b-b5af-424f-9ada-c1c1b2d416b9;response_type=code;scope=openid profile email

  3. On the app’s Overview page, click the Endpoints tab, and copy the OpenID Connect metadata document URI: Use it to configure the well_known_discovery_uri in the neo4j.conf file.

    dbms.security.oidc.azure.well_known_discovery_uri=https://login.microsoftonline.com/54e85725-ed2a-49a4-a19e-11c8d29f9a0f/v2.0/.well-known/openid-configuration

  4. Configure Neo4j to use Entra ID authentication in the neo4j.conf file:

    dbms.security.authentication_providers=oidc-azure
dbms.security.authorization_providers=oidc-azure
dbms.security.oidc.azure.display_name=Azure
dbms.security.oidc.azure.auth_flow=pkce
dbms.security.oidc.azure.config=token_type_principal=id_token;token_type_authentication=id_token

    Always use pkce auth flow. It adds an additional layer of security to the authorization code flow, which prevents certain types of attacks, such as authorization code interception attacks.

    implicit flow has been removed from OAuth 2.1 because it exposes the ID token in the browser history and the redirect URL, in addition to other security vulnerabilities. Starting with Neo4j 2026.06, its support is deprecated and will be removed in a future release.

  5. Configure which JWT claim should be used for usernames. Possible values are sub, email, or preferred_username.

    sub is the only claim guaranteed to be unique and stable. For details, see Microsoft documentation as well as the OpenId spec.

    		 
    dbms.security.oidc.azure.claims.username=sub

Map Entra groups to Neo4j roles

Decide whether you want to use Entra groups directly or Entra App Roles.

Using Entra groups directly might be convenient if you already have users assigned to those groups and want to perform Group-to-Role mapping in the neo4j.conf file.

Entra App Roles allow a layer of separation between Neo4j roles and groups. When App Roles are used, only the roles relevant to Neo4j are sent in the JWT token. This prevents leaking permissions between applications. JWT tokens also have a limitation of 200 roles per token per user, which can be avoided by sending only the relevant App Roles.

Details about Entra ID App Roles can be found in the Microsoft documentation.

Using Entra groups directly

  1. From the App registrations page, select your application.

  2. From the left-hand side menu, navigate to Manage → Manifest.

  3. Verify that the server is configured to return the Group Object IDs in the JWT identity tokens. See Microsoft documentation for details on when to use which and how it can help with the 200 roles limit described in Map Entra groups to Neo4j roles.

  4. From the left-hand side menu, navigate to Microsoft Entra ID → Groups.

  5. Create groups and assign users to them. Take note of the Object Id column.

  6. Configure a mapping from Entra Group Object Ids to Neo4j roles. For details, see Map the identity provider groups to the Neo4j roles.

    dbms.security.oidc.azure.authorization.group_to_role_mapping= "e8b6ddfa-688d-4ace-987d-6cc5516af188" = admin; \
"9e2a31e1-bdd1-47fe-844d-767502bd138d" = reader

  7. Configure Neo4j to use the groups field from the JWT token.

    dbms.security.oidc.azure.claims.groups=groups

Using Entra ID App roles

  1. From the left-hand side menu, navigate to App roles and add the Neo4j roles to the Microsoft Entra ID.

    1. Click Create app role.

    2. Fill in the fields:

      1. Display name: admin

      2. Allowed member types: Users/Groups

      3. Value: admin.
        The Value column must either correspond to the Neo4j roles or be mapped in the neo4j.conf file.

      4. Description: Neo4j admin role

    3. Click Apply.

  2. Repeat the previous step for the other roles you want to add.

  3. Configure a mapping from Entra App Roles to Neo4j roles in the neo4j.conf file. For details, see Map the identity provider groups to the Neo4j roles.

    dbms.security.oidc.azure.authorization.group_to_role_mapping= "managers" = admin; \
                                                              "engineers" = reader

  4. Configure Neo4j to use the roles field from the JWT token.

    dbms.security.oidc.azure.claims.groups=roles

  5. (Optional) If you want control the authentication and authorization on a user level, configure dbms.security.require_local_user to true in the neo4j.conf file. This setting mandates that users with the relevant auth provider attached to them must exist in the database before they can authenticate and authorize with that auth provider. For information on how to create users in this mode, see Creating users.

    For example, to create a user jake who can authenticate and authorize using Azure, you can use the following Cypher query:

    CREATE USER jake
SET HOME DATABASE 'jakesHomeDb'
SET AUTH 'oidc-azure' {SET ID 'jakesUniqueAzureUserId'} // `jakesUniqueAzureUserId` must match the value of the claim that you configured via dbms.security.oidc.azure.claims.username

    See Configure SSO at the user level using auth providers for further examples.

Google

ID token

This example shows how to use Google OpenID Connect for authentication using ID tokens in conjunction with native authorization.

  1. Configure the client and the redirect URI:

    oidc google client creation
    Figure 2. Google OIDC client creation
    oidc google client config
    Figure 3. Google OIDC client configuration

    SSO authorization does not work with Google, as the JWT returned by Google does not contain information about the groups that a user belongs to, and cannot be configured to. Therefore, it is recommended to use native (or another flavor) authorization by creating a native version of the user in Neo4j.

  2. Configure Neo4j to use Google authentication by setting the following configurations in the neo4j.conf file:

    dbms.security.authentication_providers=oidc-google
dbms.security.authorization_providers=native
dbms.security.oidc.google.display_name=Google
dbms.security.oidc.google.auth_flow=pkce
dbms.security.oidc.google.well_known_discovery_uri=https://accounts.google.com/.well-known/openid-configuration
dbms.security.oidc.google.audience=345461137297-v9brpjmgbvbm3d5s9fq65tktevosd3rn.apps.googleusercontent.com
dbms.security.oidc.google.claims.username=email
dbms.security.oidc.google.params=client_id=345461137297-v9brpjmgbvbm3d5s9fq65tktevosd3rn.apps.googleusercontent.com;response_type=code;scope=openid profile email
dbms.security.oidc.google.token_params=client_secret=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
dbms.security.oidc.google.config=token_type_principal=id_token;token_type_authentication=id_token

    Always use pkce auth flow. It adds an additional layer of security to the authorization code flow, which prevents certain types of attacks, such as authorization code interception attacks.

    implicit flow has been removed from OAuth 2.1 because it exposes the ID token in the browser history and the redirect URL, in addition to other security vulnerabilities. Starting with Neo4j 2026.06, its support is deprecated and will be removed in a future release.

  3. Using one of the following options, create a user in the database who can authenticate and authorize natively to be able to give the users roles from native authorization.

    This approach relies on the existence of an admin user who can authenticate natively and then create less privileged users via auth providers, who can authenticate only using oidc-google, but will receive the roles granted to them using native authorization.

    An admin user with the name neo4j is created by default when the database is first started.

    1. In the neo4j.conf file, temporarily enable native authentication for the admin user only and enable the user-level control of authentication and authorization:

      dbms.security.authentication_providers=oidc-google, native
dbms.security.require_local_user=true

      This will switch to user auth providers mode whereby users can only authenticate and authorize if they have a corresponding auth provider in the database.

    2. Create a user who can authenticate and authorize only using oidc-google:

      CREATE USER jake
SET HOME DATABASE 'jakesHomeDb'
SET AUTH 'oidc-google' {SET ID 'jakesUniqueGoogleUserId'} (1)
      1 jakesUniqueGoogleUserId must match the value of the claim that you configured via dbms.security.oidc.google.claims.username.

    3. Grant the user jake roles, for example, reader:

      GRANT ROLE reader TO jake

      The user implicitly receives native authorization because native is in the list of authorization providers and you have explicitly granted the user a role.

    4. Once you have set up your users in this way, you can disable native authentication for the database completely. This will prevent all users, including the admin, from logging in with a username and password:

      dbms.security.authentication_providers=oidc-google

    Alternatively, if you do not use auth providers, you can temporarily enable native authentication to create an SSO-authenticated admin user alice who can then create other users who can only authenticate using SSO.

    1. Temporarily enable native authentication:

      dbms.security.authentication_providers=oidc-google, native

    2. Create an SSO-authenticated admin user (in this example an equivalent of [email protected] must be set up in the Google SSO provider and their credentials must be known):

      CREATE USER `[email protected]` SET PASSWORD 'secretpassword';
GRANT ROLE admin to `[email protected]`;

    3. Disable native authentication for the database to prevent users logging in with username and password:

      dbms.security.authentication_providers=oidc-google

    4. Log in via Google SSO as [email protected], the admin user.

    5. Create other users who can authenticate only using oidc-google and will receive the roles granted to them using native authorization.

      CREATE USER jakesUniqueGoogleUserId (1)
SET HOME DATABASE 'jakesHomeDb'
SET PASSWORD 'secretpassword' SET PASSWORD CHANGE NOT
REQUIRED
      1 jakesUniqueGoogleUserId must match the value of the claim that you configured via dbms.security.oidc.google.claims.username.

    6. Grant the user roles using native authorization:

      GRANT ROLE reader TO jakesUniqueGoogleUserId

FAQ

Some frequently asked questions and answers about SSO configuration.

Is Google authentication secure if it has a client secret listed in the config?

Yes. Google uses the pkce flow, but identity providers sometimes also use a client secret to ensure the client asking for a token is the one using it (pkce does not guarantee that). The client secret does not add any additional security as it is public but the pkce flow provides sufficient security.

Could not parse JWT of type "access_token"

When getting the message Failed to get credentials: Could not parse JWT of type "access_token" on Browser, it probably means the provider only accepts ID tokens.

oidc access token error
Figure 4. Failed to parse JWT of type access_token

Change to ID tokens in your neo4j.conf:

dbms.security.oidc.google.config=token_type_principal=id_token;token_type_authentication=id_token

When should identity tokens vs. access tokens be used?

It is generally safer to use access tokens when possible due to being shorter-lived. If authorization permissions change on the identity provider, Neo4j will fail authorization. Neo4j Browser will try to reconnect and reflect the changed permissions faster than if ID tokens were used.

Debug logging of JWT claims

While setting up an OIDC integration, it is sometimes necessary to perform troubleshooting. In these cases, it can be useful to view the claims contained in the JWT supplied by the identity provider.

To enable the logging of these claims at DEBUG level in the security log, set dbms.security.logs.oidc.jwt_claims_at_debug_level_enabled to true and the security log level to DEBUG. You can do this in <NEO4J_HOME>/conf/server-logs.xml.

If you need more information on how to set up and manage the security log, see Configure the security log.

Make sure to set dbms.security.logs.oidc.jwt_claims_at_debug_level_enabled back to false for production environments to avoid unwanted logging of potentially sensitive information. Also, bear in mind that the set of claims provided by an identity provider in the JWT can change over time.

How to debug further problems with the configuration

Apart from the logs available in logs/debug.log and logs/security.log in the Neo4j path, you can also use the web-development console in your web browser when doing the SSO authentication flow with Bloom or Neo4j Browser. This could reveal potential problems, such as the one presented below with an example identity provider and the Cross-Origin Request policy:

oidc cors error
Figure 5. CORS error

The solution involves adding the redirect domain to the list of allowed domains in the provider (in this case, localhost:8080):

oidc cors error solution
Figure 6. CORS error solution allowing the redirect domain on the provider

Glossary

allocator

A component in the cluster that allocates databases to servers according to the topology constraints specified and an allocation strategy.

asynchronous replication

Asynchronous replication is used by secondary copies to poll for new transactions, which means they cannot be guaranteed to have received the most recent transactions. This enables efficient scale-out of read-performance.

Aura instance

A fully-managed DBMS represented by a single instance ID, that is running in the Neo4j Aura cloud.

auto-commit transaction

An automatically committed transaction that contains a single query.

Bolt protocol

Bolt is a protocol used for interaction between Neo4j instances and drivers.

bookmark

A marker the client can request from the cluster to ensure that it is able to read its own writes so that the application’s state is consistent and only databases that have a copy of the bookmark are permitted to respond.

category (Bloom)

A category is based on a node label and is defined in a Perspective as a way of visually distinguishing nodes with the same label(s).

causal consistency

All servers in a cluster agree on the order in which transactions take place. The position of a server on the causal chain can be guaranteed using a bookmark.

cluster

A Neo4j DBMS that spans multiple servers working together to increase fault tolerance and/or read scalability. Databases on a cluster may be configured to replicate across servers in the cluster thus achieving read scalability or high availability.

client application

Software that interacts with a Neo4j server.

commit

A commit is the successful completion of a transaction, which ensures durability of any changes made. For more details, visit Operations Manual → Transaction management.

composite database

Composite databases are the means to access partitioned graph data with a single Cypher query.

constraint

Constraints are sets of data modeling rules that ensure the data is consistent and reliable.

Cypher®

Neo4j’s graph query language.

data model

A data model defines how information is organized in a database. A good data model will make querying and understanding your data easier. In Neo4j, the data models have a graph structure.

database

A database is a container used by the DBMS to manage and store graph data. The physical structure of data is controlled by the database.

database vs graph

Databases are the physical containers of graph data. Graphs are the logical structure of data in Neo4j.

Database Management System

Database Management System, or DBMS, capable of managing multiple databases. A DBMS may run on a single server, or span several servers configured as a cluster.

database schema

The prescribed property existence and datatypes for nodes and relationships.

deallocate

An act of removing a database from a server or a server from a cluster without loss of data or reduced fault tolerance.

degree (of a node)

The number of relationships of a specific node; loops are counted twice.

disaster recovery

A manual intervention to restore availability of a cluster, or databases within a cluster.

driver

A software library that provides access to Neo4j from a particular programming language.

election

In the event that the Raft leader becomes unresponsive, followers automatically trigger an election and vote for a new leader.

entity

A node or a relationship.

expression (Cypher)

A component of a Cypher query which produces values. It may be used in projections, as a predicate, or when setting properties on graph elements.

fabric

Fabric is the architectural design of a unified system that provides a single access point to local or distributed graph data.

fault tolerance

A guarantee that a cluster can maintain a database’s persistence and availability in the event of one or more servers failing.

follower

A primary copy of a database acting as a follower, receives and acknowledges synchronous writes from the leader.

Generative AI (GenAI)

A type of artificial intelligence (AI) system that generates text, images, or other media in response to prompts.

graph

A logical representation of a set of nodes where some pairs are connected by relationships.

index

Data structure that improves read performance of a database.

knowledge graph

A specific type of graph that has an organizing principle so that a user (or a computer system) can reason about the underlying data. The organizing principle provides an additional layer of structure that adds context to support knowledge discovery.

label

Marks a node as a member of a named and indexed subset. A node may be assigned zero or more labels.

leader

A single primary copy of a database is designated as the leader. It receives all write transactions from clients and replicates writes synchronously to followers and asynchronously to secondary copies of the database.

main database

In terms of Neo4j Enterprise Studio, the database(s) containing the user’s data. Can exist in the same Neo4j deployment as the tool asset database.

motif

A description of a specific pattern within a graph.

node

A node represents an entity or discrete object in your graph data model. Nodes can be connected by relationships, hold data in properties, and are classified by labels.

operator

A symbol representing a mathematical or logical operation.

parameter

Named value provided when running a Cypher statement.

path

A sequence of nodes and the relationships connecting them, that does not contain duplicate relationships. Several paths can match a pattern.

pattern

A specific arrangement of nodes and relationships that can be matched in a graph. A pattern follows a motif.

perspective (Bloom)

A Perspective defines a certain business view or domain that can be found in the target Neo4j graph. A single Neo4j graph can be viewed through different Perspectives, each tailored for a different business purpose.

primary

A copy of the database that is able to process write transactions and is eligible to be elected as a leader. It participates in fault tolerant writes as it is part of the majority required to acknowledge and commit write transactions.

primary vs secondary

In a cluster, databases can operate in either primary or secondary mode. Primary databases are able to process write and read transactions, ensuring fault tolerance. Secondary databases are replicated asynchronously from primaries, and their main purpose is to provide read scaling within the cluster.

project (Aura)

An isolated environment in the unified Aura console that contains its own database instances, configurations, and resources. Preceded by tenant in the classic Aura console.

property

Properties are key-value pairs that are used for storing data on nodes and relationships.

query (Cypher)

A statement that retrieves or writes information to a database.

Raft group

A group of servers that are participating in hosting a particular database in primary mode.

Raft group member

A server that is participating in a Raft group. A server can be a member of one or more groups.

Raft log

A shared log between all Raft group members that is guaranteed to be consistently updated and viewed by those members. The log contains both database data and operational state of the Raft group.

Raft protocol

The networking mechanism that enables a database to replicate its data across multiple servers to give high availability for accessing the data and high durability to the data stored.

read scaling

Distributing query load by creating additional database copies hosted in secondary mode (read-only).

relationship

A relationship represents a connection between nodes in your graph data model. Relationships connect a source node to a target node, hold data in properties, and are classified by type.

secondary

An asynchronously replicated copy of the database that provides read scaling within the cluster.

seed

A seed is a database dump or a full backup used to create a database on a cluster. This is sometimes called seeding.

server

A physical machine, a virtual machine, or a container running an instance of Neo4j. Servers can be standalone or part of a cluster.

session

A causally linked sequence of transactions.

session consistency

An alternative name for Neo4j’s causal consistency.

standalone

A single server running Neo4j and not part of a cluster.

synchronous replication

Synchronous replication requires the leader primary to replicate a transaction and block the commit until a quorum of the follower primaries acknowledges that the transaction is successfully replicated. Once the transaction is replicated, the commit is allowed to proceed. This ensures data durability and consistency within the cluster.

system database

A database used by Neo4j to store system information.

tenant (Aura)

An isolated environment in the classic Aura console that contains its own database instances, configurations, and resources. Replaced by project in the unified Aura console.

tool asset database

In terms of Neo4j Enterprise Studio, the database where tools' assets are stored. This can be in the same Neo4j deployment as the main database(s) or in a separate deployment.

topology

A configuration that describes how the copies of a database should be spread across the servers in a cluster, see primary mode and secondary mode.

transaction

A transaction comprises a unit of work performed against a database. It is treated in a coherent and reliable way, independent of other transactions. Transactions comply with the ACID consistency model (atomic, consistent, isolated, and durable).