Database management
This section explains how to use Cypher® to manage databases in Neo4j DBMS: creating, modifying, deleting, starting, and stopping individual databases within a single server.
Neo4j supports the management of multiple databases within the same DBMS.
The metadata for these databases, including the associated security model, is maintained in a special database called the system
database.
All multi-database administrative commands must be run against the system
database.
These administrative commands are automatically routed to the system
database when connected to the DBMS over Bolt.
The syntax of the database management commands is as follows:
More details about the syntax descriptions can be found here. |
Command | Syntax |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Listing databases
There are four different commands for listing databases:
-
Listing all databases.
-
Listing a particular database.
-
Listing the default database.
-
Listing the home database.
These commands return the following columns:
Column | Description | ||
---|---|---|---|
|
The name of the database. Default Output |
||
|
The names of any aliases the database may have. Default Output |
||
|
The database access mode, either |
||
|
The database unique ID. |
||
|
The server instance ID. |
||
|
Instance address in a clustered DBMS.
The default for a standalone database is |
||
|
The current role of the database ( |
||
|
The expected status of the database. Default Output |
||
|
The actual status of the database. Default Output |
||
|
An error message explaining why the database is not in the correct state. Default Output |
||
|
Show if this is the default database for the DBMS. Default Output
|
||
|
Shown if this is the home database for the current user. Default Output
|
||
|
The ID of the last transaction received. |
||
|
Number of transactions the current database is behind compared to the database on the primary instance.
The lag is expressed in negative integers. In standalone environments, the value is always |
A summary of all available databases can be displayed using the command SHOW DATABASES
.
SHOW DATABASES
name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rows: 3 |
The results of this command are filtered according to the |
In this example, the detailed information for a particular database can be displayed using the command SHOW DATABASE name YIELD *
.
When a YIELD
clause is provided, the full set of columns is returned.
SHOW DATABASE movies YIELD *
name | aliases | access | databaseID | serverID | address | role | requestedStatus | currentStatus | error | default | home | lastCommittedTxn | replicationLag |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rows: 1 |
The number of databases can be seen using a count()
aggregation with YIELD
and RETURN
.
SHOW DATABASES YIELD *
RETURN count(*) AS count
count |
---|
|
Rows: 1 |
The default database can be seen using the command SHOW DEFAULT DATABASE
.
SHOW DEFAULT DATABASE
name | aliases | access | address | role | requestedStatus | currentStatus | error |
---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
Rows: 1 |
The home database for the current user can be seen using the command SHOW HOME DATABASE
.
SHOW HOME DATABASE
name | aliases | access | address | role | requestedStatus | currentStatus | error |
---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
Rows: 1 |
It is also possible to filter and sort the results by using YIELD
, ORDER BY
, and WHERE
.
SHOW DATABASES YIELD name, currentStatus, requestedStatus
ORDER BY currentStatus
WHERE name CONTAINS 'e'
In this example:
-
The number of columns returned has been reduced with the
YIELD
clause. -
The order of the returned columns has been changed.
-
The results have been filtered to only show database names containing
'e'
. -
The results are ordered by the
currentStatus
column usingORDER BY
.
It is also possible to use SKIP
and LIMIT
to paginate the results.
name | currentStatus | requestedStatus |
---|---|---|
|
|
|
|
|
|
|
|
|
Rows: 3 |
Note that for failed databases, the |
Creating databases
Databases can be created using CREATE DATABASE
.
CREATE DATABASE customers
System updates: 1
Rows: 0
Database names are subject to the standard Cypher restrictions on valid identifiers. The following naming rules apply:
|
When a database has been created, it will show up in the listing provided by the command SHOW DATABASES
.
SHOW DATABASES
name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rows: 4 |
Handling Existing Databases
This command is optionally idempotent, with the default behavior to fail with an error if the database already exists.
Appending IF NOT EXISTS
to the command ensures that no error is returned and nothing happens should the database already exist.
Adding OR REPLACE
to the command will result in any existing database being deleted and a new one created.
CREATE DATABASE customers IF NOT EXISTS
CREATE OR REPLACE DATABASE customers
This is equivalent to running DROP DATABASE customers IF EXISTS
followed by CREATE DATABASE customers
.
The |
Options
The create database command can have a map of options, e.g. OPTIONS {key: 'value'}
.
Key | Value | Description |
---|---|---|
|
|
Controls how the system handles existing data on disk when creating the database.
Currently this is only supported with |
|
instance ID of the cluster node |
Defines which instance is used for seeding the data of the created database.
The instance id can be taken from the id column of the |
The |
Altering databases
Databases can be modified using the command ALTER DATABASE
.
For example, a database always has read-write access mode on creation, unless the configuration parameter dbms.databases.default_to_read_only
is set to true
.
To change it to read-only, you can use the ALTER DATABASE
command with the sub-clause SET ACCESS READ ONLY
.
Subsequently, the database access mode can be switched back to read-write using the sub-clause SET ACCESS READ WRITE
.
Altering the database access mode is allowed at all times, whether a database is online or offline.
Database access modes can also be managed using the configuration parameters dbms.databases.default_to_read_only
, dbms.databases.read_only
, and dbms.database.writable
.
For details, see Configuration parameters.
If conflicting modes are set by the ALTER DATABASE
command and the configuration parameters, i.e. one says read-write and the other read-only, the database will be read-only and prevent write queries.
ALTER DATABASE customers SET ACCESS READ ONLY
System updates: 1
Rows: 0
The database access mode can be seen in the access
output column of the command SHOW DATABASES
.
SHOW DATABASES yield name, access
name | access |
---|---|
|
|
|
|
|
|
|
|
Rows: 4 |
This command is optionally idempotent, with the default behavior to fail with an error if the database does not exist.
Appending IF EXISTS
to the command ensures that no error is returned and nothing happens should the database not exist.
ALTER DATABASE nonExisting IF EXISTS
SET ACCESS READ WRITE
Stopping databases
Databases can be stopped using the command STOP DATABASE
.
STOP DATABASE customers
System updates: 1
Rows: 0
The status of the stopped database can be seen using the command SHOW DATABASE name
.
SHOW DATABASE customers
name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Rows: 1 |
Starting databases
Databases can be started using the command START DATABASE
.
START DATABASE customers
System updates: 1
Rows: 0
The status of the started database can be seen using the command SHOW DATABASE name
.
SHOW DATABASE customers
name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Rows: 1 |
Deleting databases
Databases can be deleted using the command DROP DATABASE
.
DROP DATABASE customers
System updates: 1
Rows: 0
When a database has been deleted, it will no longer show up in the listing provided by the command SHOW DATABASES
.
SHOW DATABASES
name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rows: 3 |
This command is optionally idempotent, with the default behavior to fail with an error if the database does not exist.
Appending IF EXISTS
to the command ensures that no error is returned and nothing happens should the database not exist.
It will always return an error, if there is an existing alias that targets the database. In that case, the alias needs to be dropped before dropping the database.
DROP DATABASE customers IF EXISTS
The DROP DATABASE
command will remove a database entirely.
You can request that a dump of the store files is produced first, and stored in the path configured using the dbms.directories.dumps.root
setting (by default <neo4j-home>/data/dumps
).
This can be achieved by appending DUMP DATA
to the command (or DESTROY DATA
to explicitly request the default behavior).
These dumps are equivalent to those produced by neo4j-admin dump
and can be similarly restored using neo4j-admin load
.
DROP DATABASE customers DUMP DATA
The options IF EXISTS
and DUMP DATA
/ DESTROY DATA
can also be combined.
An example could look like this:
DROP DATABASE customers IF EXISTS DUMP DATA
Wait options
Aside from SHOW DATABASES
and ALTER DATABASE
, all database management commands accept an optional WAIT
/NOWAIT
clause. The WAIT
/NOWAIT
clause allows you to specify a time limit in which the command must complete and return.
The options are:
-
WAIT n SECONDS
- Return once completed or when the specified time limit ofn
seconds is up. -
WAIT
- Return once completed or when the default time limit of 300 seconds is up. -
NOWAIT
- Return immediately.
A command using a WAIT
clause will automatically commit the current transaction when it executes successfully, as the command needs to run immediately for it to be possible to WAIT
for it to complete.
Any subsequent commands executed will therefore be performed in a new transaction.
This is different to the usual transactional behavior, and for this reason it is recommended that these commands be run in their own transaction.
The default behavior is NOWAIT
, so if no clause is specified the transaction will behave normally and the action is performed in the background post-commit.
A command with a |
CREATE DATABASE slow WAIT 5 SECONDS
address | state | message | success |
---|---|---|---|
|
|
|
|
Rows: 1 |
The success
column provides an aggregate status of whether or not the command is considered successful and thus every row will have the same value.
The intention of this column is to make it easy to determine, for example in a script, whether or not the command completed successfully without timing out.