Import header format

CSV header format

The header file of each data source specifies how the data fields should be interpreted. You must use the same delimiter for the header file and the data files.

The header contains information for each field, with the format <name>:<field_type>. The <name> is used for properties and node IDs. In all other cases, the <name> part of the field is ignored.

Incremental import special requirements

When using Incremental import, you must have node property uniqueness constraints in place for the property key and label combinations that form the primary key, or the uniquely identifiable nodes. For example, importing nodes with a Person label that are uniquely identified with a uuid property key, the format of the header should be uuid:ID{label:Person}.

This is also true when working with multiple groups. For example, you can use uuid:ID(Person){label:Person}, where the relationship CSV data can refer to different groups for its :START_ID and :END_ID, just like the full import method.

For more information on constraints, see Cypher Manual → Constraints.
For examples of creating property uniqueness constraints, see Cypher Manual → Create property uniqueness constraints.

Extended header support for Parquet
Introduced in 2025.04

In addition to the header format supported by the CSV import, the Parquet import supports name-mapping header files. Those files contain two rows of entries, where the first row represents the name (incl. optional type, id group, etc.), and the second row references the name of the original columns in the data files.

movie_header.csv

movieId:ID,title,year:int,:LABEL
id,movie_title,year,label

If a header file is provided for a set of labels or a relationship type, the importer will ignore columns not mentioned in the headers.

Default data types for Parquet
Introduced in 2025.04

Unlike CSV, where an unspecified property type defaults to string (see Property data types), Parquet files carry their own type information in the file schema. Because of this, you do not have to declare the <field_type> for a property in a Parquet header. If you leave the type out, the importer picks the corresponding Neo4j type from the Parquet column’s type automatically.

For example, the following header relies on the types stored in the Parquet file for all properties:

movieId:ID,title,year,:LABEL

You can still specify a type explicitly to override the inferred one, or to request a conversion (for example, storing a Parquet INT32 column as a string).

Default Parquet-to-Neo4j type mapping

The following table shows how Parquet types are mapped to Neo4j property types when no type is given in the header.

Table 1. Default Parquet-to-Neo4j type mapping
Parquet type	Neo4j type	Notes
`BOOLEAN`	`boolean`
`INT32, INT64`	`long`	Integer logical types (`INT(8)`, `INT(16)`, `INT(32)`, `INT(64)`) are also imported as `long`.
`FLOAT, DOUBLE`	`double`
`BINARY, FIXED_LEN_BYTE_ARRAY, INT96`	`string`	Applies to the `STRING` (UTF-8) logical type and to other binary columns, which are read using their string representation.
`DATE (logical)`	`date`	Introduced in 2025.09
`TIME (logical)`	`time / localtime`	Introduced in 2025.09 Mapped to `time` when the column is adjusted to UTC, and to `localtime` otherwise.
`TIMESTAMP (logical)`	`datetime / localdatetime`	Introduced in 2025.09 Mapped to `datetime` when the column is adjusted to UTC, and to `localdatetime` otherwise.
`INTERVAL (logical)`	`duration`	Introduced in 2026.07
`LIST (logical)`	`array`	Introduced in 2025.02 Imported as an array of the mapped element type, for example, a `LIST` of `INT64` becomes a `long[]`.
`MAP (logical)`	`individual properties`	Introduced in 2025.02 Each entry becomes its own property. See Map columns.

Map columns

Neo4j properties cannot hold a map value, so a Parquet MAP column is not stored as a single property. Instead, each entry in the map is extracted into its own property, named <column>.<key>, where <column> is the name of the Parquet column and <key> is the key of the map entry. The value of each property is converted according to the same type mapping as any other column. Entries whose value is null are skipped and do not create a property.

For example, a Parquet column named address holding a map with the keys city and zip results in two properties, address.city and address.zip, on the imported node or relationship.

Struct (nested group) columns are extracted in the same way, producing one <column>.<field> property per nested field.

Node files

Files containing node data can have an ID field, a LABEL field, and properties.

ID: Each node must have a unique ID if it is to be connected by any relationships created in the import. Neo4j uses the IDs to find the correct nodes when creating relationships. Note that the ID has to be unique across all nodes within the group, regardless of their labels. The unique ID is persisted in a property whose name is defined by the <name> part of the field definition <name>:ID. If no such property name is defined, the unique ID will be used for the import but not be available for reference later. If no ID is specified, the node will be imported, but it will not be connected to other nodes during the import. When a property name is provided, that property type can be configured globally via the --id-type option (as for Property data types).
You can specify a different value ID type to be stored for a node property in its group using the option id-type in the header, e.g: id:ID(MyGroup){label:MyLabel, id-type: int}. This ID type overrides the global --id-type option. For example, the global id-type can be a string, but the nodes will have their IDs stored as int type in their ID properties. For more information, see Storing a different value type for IDs in a group.
A node header can also contain multiple ID columns, where the relationship data references the composite value of all those columns. This also implies using string as id-type. For each ID column, you can specify to store its values as different node properties. However, the composite value cannot be stored as a node property. For more information, see Using multiple node IDs (full import only).
LABEL: Read one or more labels from this field. Like array values, multiple labels are separated by ;, or by the character specified with --array-delimiter. The max length of label names for block format is 16,383 characters.

Example 1. Define node files

You define the headers for movies in the movies_header.csv file. Movies have the properties movieId, year, and title. You also specify a field for labels.

movieId:ID,title,year:int,:LABEL

You define three movies in the movies.csv file. They contain all the properties defined in the header file. All the movies are given the label Movie. Two of them are also given the label Sequel.

tt0133093,"The Matrix",1999,Movie
tt0234215,"The Matrix Reloaded",2003,Movie;Sequel
tt0242653,"The Matrix Revolutions",2003,Movie;Sequel

Similarly, you also define three actors in the actors_header.csv and actors.csv files. They all have the properties personId and name, and the label Actor.

personId:ID,name,:LABEL

keanu,"Keanu Reeves",Actor
laurence,"Laurence Fishburne",Actor
carrieanne,"Carrie-Anne Moss",Actor

Relationship files

Files containing relationship data have three mandatory fields and can also have properties. The mandatory fields are:

TYPE: The relationship type to use for this relationship. The max length of relationship type names for block format is 16,383 characters.
START_ID: The ID of the start node for this relationship.
END_ID: The ID of the end node for this relationship.

The START_ID and END_ID refer to the unique node ID defined in one of the node data sources, as explained in the previous section. None of these take a name, e.g. if <name>:START_ID or <name>:END_ID is defined, the <name> part will be ignored. Nor do they take a <field_type>, e.g. if :START_ID:int or :END_ID:int is defined, the :int part does not have any meaning in the context of type information.

Example 2. Define relationships files

In this example, you assume that the two node files from the previous example are used together with the following relationships file.

You define relationships between actors and movies in the files roles_header.csv and roles.csv. Each row connects a start node and an end node with a relationship of relationship type ACTED_IN. Notice how you use the unique identifiers personId and movieId from the nodes files above. The name of the character that the actor is playing in this movie is stored as a role property on the relationship.

:START_ID,role,:END_ID,:TYPE

keanu,"Neo",tt0133093,ACTED_IN
keanu,"Neo",tt0234215,ACTED_IN
keanu,"Neo",tt0242653,ACTED_IN
laurence,"Morpheus",tt0133093,ACTED_IN
laurence,"Morpheus",tt0234215,ACTED_IN
laurence,"Morpheus",tt0242653,ACTED_IN
carrieanne,"Trinity",tt0133093,ACTED_IN
carrieanne,"Trinity",tt0234215,ACTED_IN
carrieanne,"Trinity",tt0242653,ACTED_IN

Property data types

For properties, the <name> part of the field designates the property key, while the <field_type> part assigns a data type. You can have properties in both node data files and relationship data files. The max length of property keys for block format is 16,383 characters.

Use one of int, long, float, double, boolean, byte, short, char, string, point, date, localtime, time, localdatetime, datetime, duration, and vector (introduced in 2025.10) to designate the data type for properties. By default, types (except arrays) are converted to Cypher types. See Cypher Manual → Property, structural, and constructed values.

This behavior can be disabled using the option --normalize-types=false. Normalizing types can require more space on disk, but avoids Cypher converting the type during queries. If no data type is given, this defaults to string.

To define an array type, append [] to the type. By default, array values are separated by ;. A different delimiter can be specified with --array-delimiter. Arrays are not affected by the --normalize-types flag. For example, if you want a byte array to be stored as a Cypher long array, you must explicitly declare the property as long[].

Array values can also be sourced directly from a LIST typed column with Parquet files, in which case the --array-delimiter option is not needed. Furthermore, values read from LIST typed columns are mapped to their corresponding Cypher types, e.g., LIST<INT> is mapped to int[], LIST<STRING> is mapped to string[], and so on, and there is no need to specify the type in the header.

CSV-based import does not import empty arrays, because they cannot be distinguished from arrays that are set to null. However, the Parquet import distinguishes between them and will import empty arrays as empty arrays and null as null.

Boolean values are true if they match exactly the text true. All other values are false. Values that contain the delimiter character need to be escaped by enclosing in double quotation marks, or by using a different delimiter character with the --delimiter option.

Example 3. Header format with data types

This example illustrates several different data types specified in the CSV header.

:ID,name,joined:date,active:boolean,points:int
user01,Joe Soap,2017-05-05,true,10
user02,Jane Doe,2017-08-21,true,15
user03,Moe Know,2018-02-17,false,7

Special considerations for the point data type

A point is specified using the Cypher syntax for maps. The map allows the same keys as the input to the Cypher Manual → Point function. The point data type in the header can be amended with a map of default values used for all values of that column, e.g. point{crs: 'WGS-84'}. Specifying the header this way allows you to have an incomplete map in the value position in the data file. Optionally, a value in a data file may override default values from the header.

Example 4. Property format for point data type

This example illustrates various ways of using the point data type in the import header and the data files.

You are going to import the name and location coordinates for cities. First, you define the header as:

:ID,name,location:point{crs:WGS-84}

You then define cities in the data file.

The first city’s location is defined using latitude and longitude, as expected when using the coordinate system defined in the header.
The second city uses x and y instead. This would normally lead to a point using the coordinate reference system cartesian. Since the header defines crs:WGS-84, that coordinate reference system will be used.
The third city overrides the coordinate reference system defined in the header and sets it explicitly to WGS-84-3D.

:ID,name,location:point{crs:WGS-84}
city01,"Malmö","{latitude:55.6121514, longitude:12.9950357}"
city02,"London","{y:51.507222, x:-0.1275}"
city03,"San Mateo","{latitude:37.554167, longitude:-122.313056, height: 100, crs:'WGS-84-3D'}"

Note that all point maps are within double quotation marks " in order to prevent the enclosed , character from being interpreted as a column separator. An alternative approach would be to use --delimiter='\t' and reformat the file with tab separators, in which case the " characters are not required.

:ID name    location:point{crs:WGS-84}
city01  Malmö   {latitude:55.6121514, longitude:12.9950357}
city02  London  {y:51.507222, x:-0.1275}
city03  San Mateo   {latitude:37.554167, longitude:-122.313056, height: 100, crs:'WGS-84-3D'}

Special considerations for temporal data types

The format for all temporal data types must be defined as described in Cypher Manual → Temporal instants syntax and Cypher Manual → Durations syntax. Two of the temporal types, Time and DateTime, take a time zone parameter that might be common between all or many of the values in the data file. It is therefore possible to specify a default time zone for Time and DateTime values in the header, for example: time{timezone:+02:00} and: datetime{timezone:Europe/Stockholm}. If no default time zone is specified, the default timezone is determined by the db.temporal.timezone configuration setting. The default time zone can be explicitly overridden in the values in the data file.

Example 5. Property format for temporal data types

This example illustrates various ways of using the datetime data type in the import header and the data files.

First, you define the header with two DateTime columns. The first one defines a time zone, but the second one does not:

:ID,date1:datetime{timezone:Europe/Stockholm},date2:datetime

You then define dates in the data file.

The first row has two values that do not specify an explicit timezone. The value for date1 will use the Europe/Stockholm time zone that was specified for that field in the header. The value for date2 will use the configured default time zone of the database.
In the second row, both date1 and date2 set the time zone explicitly to be Europe/Berlin. This overrides the header definition for date1, as well as the configured default time zone of the database.

1,2018-05-10T10:30,2018-05-10T12:30
2,2018-05-10T10:30[Europe/Berlin],2018-05-10T12:30[Europe/Berlin]

Special considerations for vector data types introduced in 2025.10

A vector is specified using the Cypher syntax for maps. The map must specify both the coordinateType and the dimensions of the vector. The coordinateType can be one of byte, short, int, long, float, or double. The dimensions must be between 1 and 4096, inclusive.

The dimensions of each vector in the data must match what is specified in the header.

A vector in a header could for example look like this:

:ID,"vector1:vector{coordinateType:byte,dimensions:4096}"

Note that quotation marks are necessary, since the , inside the map would otherwise be interpreted as a column delimiter.

With CSV files and Parquet files where vector values are encoded as strings, by default, vector values are separated by ;. A different delimiter can be specified with --vector-delimiter.

Starting with Neo4j 2026.06, vector values can also be sourced from a LIST typed column with Parquet files, in which case the --vector-delimiter option is not needed.

Using ID spaces

By default, the import tool assumes that node identifiers are unique across node files. In many cases, the ID is unique only across each entity file, for example, when your CSV files contain data extracted from a relational database and the ID field is pulled from the primary key column in the corresponding table. To handle this situation you define ID spaces. ID spaces are defined in the ID field of node files using the syntax ID(<ID space identifier>). To reference an ID of an ID space in a relationship file, you use the syntax START_ID(<ID space identifier>) and END_ID(<ID space identifier>).

Example 6. Define and use ID spaces

Define a Movie-ID ID space in the movies_header.csv file.

movieId:ID(Movie-ID),title,year:int,:LABEL

1,"The Matrix",1999,Movie
2,"The Matrix Reloaded",2003,Movie;Sequel
3,"The Matrix Revolutions",2003,Movie;Sequel

Define an Actor-ID ID space in the header of the actors_header.csv file.

personId:ID(Actor-ID),name,:LABEL

1,"Keanu Reeves",Actor
2,"Laurence Fishburne",Actor
3,"Carrie-Anne Moss",Actor

Now use the previously defined ID spaces when connecting the actors to movies.

:START_ID(Actor-ID),role,:END_ID(Movie-ID),:TYPE

1,"Neo",1,ACTED_IN
1,"Neo",2,ACTED_IN
1,"Neo",3,ACTED_IN
2,"Morpheus",1,ACTED_IN
2,"Morpheus",2,ACTED_IN
2,"Morpheus",3,ACTED_IN
3,"Trinity",1,ACTED_IN
3,"Trinity",2,ACTED_IN
3,"Trinity",3,ACTED_IN

Using multiple node IDs (full import only)

A node header can contain multiple ID columns.

Starting from 2025.07, the relationship data must then use a matching number of START_ID / END_ID columns as references to the composite value of those ID columns. This implies using string as id-type.

For each ID column, you can specify to store its values as different node properties. However, the composite value cannot be stored as a node property.

Define multiple IDs as node properties

Define multiple ID columns in the node header.
nodes_header.csv
```
:ID,:ID,name
```
nodes.csv
```
aa,11,John
bb,22,Paul
```
Define the relationship between two established nodes.
Starting from 2025.07, you can use a matching number of START_ID and END_ID columns when defining the relationship. However, do not mix how to refer to composite IDs. Either all references must use a single START_ID and END_ID column or all references must use a matching number of them.

relationships_header.csv

:START_ID,:START_ID,:TYPE,:END_ID,:END_ID

relationships.csv

aa,11,WORKS_WITH,bb,22
Now use both IDs when defining the relationship:

relationships_header.csv

:START_ID,:TYPE,:END_ID

relationships.csv

aa11,WORKS_WITH,bb22

Define multiple IDs stored in ID spaces

Define a MyGroup ID space in the nodes_header.csv file.
nodes_header.csv
```
personId:ID(MyGroup),memberId:ID(MyGroup),name
```
nodes.csv
```
aa,11,John
bb,22,Paul
```
Now use the defined ID space when connecting John with Paul, and use both IDs in the relationship.
Starting from 2025.07, you have to use a matching number of START_ID and END_ID columns when defining the relationship:

relationships_header.csv

:START_ID(MyGroup),:START_ID(MyGroup),:TYPE,:END_ID(MyGroup),:END_ID(MyGroup)

relationships.csv

aa,11,WORKS_WITH,bb,22
relationships_header.csv

:START_ID(MyGroup),:TYPE,:END_ID(MyGroup)

relationships.csv

aa11,WORKS_WITH,bb22

Storing a different value type for IDs in a group

You can control the ID type of the node property that will be stored by defining the id-type option in the header, for example, :ID{id-type:long}. The id-type option in the header overrides the global --id-type value provided to the command. This way, you can have property values of different types for different groups of nodes. For example, the global id-type can be a string, but some nodes can have their IDs stored as long type in their ID properties.

Example 7. Import nodes with different ID value types

persons_header.csv

id:ID(GroupOne){id-type:long},name,:LABEL

persons.csv

123,P1,Person
456,P2,Person

games_header.csv

id:ID(GroupTwo),name,:LABEL

games.csv

ABC,G1,Game
DEF,G2,Game

Import the nodes

neo4j_home$ --nodes persons.csv --nodes games.csv --id-type string

The id property of the nodes in the persons group will be stored as long type, while the id property of the nodes in the games group will be stored as string type, as the global id-type is a string.

Importing data that spans multiple lines

The --multiline-fields option allows fields from an input source to span multiple lines, i.e. contain newline characters. For example:

bin/neo4j-admin database import full \
--nodes=import/node_header.csv,import/node_data.csv \
--multiline-fields=true \
databasename

Where import/node_data.csv contains multiline fields, such as:

id,name,birthDate,birthYear,birthLocation,description
1,John,October 1st,2000,New York,This is a multiline
description

Setting --multiline-fields=true can severely degrade the performance of the importer. Therefore, use it with care, especially with large imports.

Optionally, you can specify the format of the --multiline-fields to control the parsing of the input source by setting the --multiline-fields-format option. Possible values are:

v1 - the default format, which uses the current processing method for multiline fields.
v2 - a more efficient processing method that requires text fields to be quoted. For v2, the --multiline-fields option must be set to a list of files (regular expressions are allowed) that contain multiline fields.

Both formats have the restriction that the entirety of every row must be able to fit into the buffer (default is 4m). The --multiline-fields-format option is available in the full and incremental import modes.

For example:

bin/neo4j-admin database import full \
--nodes=import/node_header.csv,import/node_data.csv \
--multiline-fields=true \
--multiline-fields-format=v1 \
databasename

Where import/node_data.csv contains multiline fields, such as:

id,name,birthDate,birthYear,birthLocation,description
1,John,October 1st,2000,New York,This is a multiline
description

bin/neo4j-admin database import full \
--nodes=import/node_header.csv,import/node_data.csv \
--multiline-fields=import/node_data.csv \
--multiline-fields-format=v2 \
databasename

Where import/node_data.csv contains multiline fields, such as:

id,name,birthDate,birthYear,birthLocation,description
1,"John","October 1st",2000,"New York","This is a multiline
description"

Skipping columns

IGNORE

If there are fields in the data that you wish to ignore completely, this can be done using the IGNORE keyword in the header file. IGNORE must be prepended with a :.

Example 8. Skip a column

In this example, you are not interested in the data in the third column of the nodes file and wish to skip over it. Note that the IGNORE keyword is prepended by a :.

personId:ID,name,:IGNORE,:LABEL

keanu,"Keanu Reeves","male",Actor
laurence,"Laurence Fishburne","male",Actor
carrieanne,"Carrie-Anne Moss","female",Actor

If all your superfluous data is placed in columns located to the right of all the columns that you wish to import, you can instead use the command line option --ignore-extra-columns.

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

Import header format

CSV header format

Incremental import special requirements

Extended header support for ParquetIntroduced in 2025.04

Default data types for ParquetIntroduced in 2025.04

Default Parquet-to-Neo4j type mapping

Map columns

Node files

Relationship files

Property data types

Using ID spaces

Using multiple node IDs (full import only)

Define multiple IDs as node properties

Define multiple IDs stored in ID spaces

Storing a different value type for IDs in a group

Importing data that spans multiple lines

Skipping columns

Glossary

Extended header support for Parquet
Introduced in 2025.04

Default data types for Parquet
Introduced in 2025.04