Enterprise Databases
To upgrade/downgrade an Enterprise database, please contact our support engineers. They will walk you through the process, schedule a suitable time window and perform the upgrade/downgrade of your database.
## Overview
There are 2 ways of upgrading/downgrading your plan on GrapheneDB:
[In-place. (Only available on Performance tier)](🔗)
[Using cloning feature](🔗)
## Changing your database plan in-place
This feature is only available on our Performance tier. For changing plans on other tiers, as well as further options like upgrading Neo4j, please use our cloning feature.
Please follow these steps to change your plan in-place:
Put your application in maintenance mode.
Click on Upgrade plan button. A modal window will be shown.
Select the plan you want to change to and click on Upgrade database button.
Test that everything is working correctly on your end.
Put your application back to normal mode.
**There is no action required on your side**. Extensions, indexes and connection settings are not going to change after the operation.
If you want to downgrade plan, please **make sure that the new plan features enough disk and resources for your dataset and load**.
Downtime
Please take into account that the operation involves database downtime. The downtime duration can vary depending on the size of your database and the time Neo4j needs to stop it. There will be always less downtime changing your plan in-place than via cloning option. Please contact our support team if you have any questions about downtime.
## Changing your database plan via cloning
GrapheneDB supports changing the plan of a Neo4j database as a self-service operation via our _Cloning by export_ feature.
Clone operation
The described procedure works by creating a new database from a copy of the original instance. After the operation is completed, **the original database will continue to run**. It is up the user to delete it when it is no longer needed. Any modifications to the original database after the clone process is started will not be reflected in the new instance.
## Steps
To perform a database plan upgrade on your own follow these steps :
Stop requests to the database. Any write request that hits the database after the clone process is started, will not be replicated on the destination database, potentially resulting in data loss.
Click on the _Upgrade/Clone_ button
Select _Clone by exporting_ and **select a higher plan** for the new database
Once completed, verify that the clone process went well and everything looks good.
Create a new user for the new database
Update the Neo4j endpoint and credentials in your code to point to the new database/user
Resume requests to the database, making sure to hit the new database only
If you want to downgrade instead, please **make sure the the new plan features enough disk and resources for your dataset and workload.**
Please contact our support team if you have any questions or issues.
Please keep in mind that the Internal Id of your database will change after you upgrade your instance.
Downtime
Please take into account that this operation involves downtime. More details below.
## Downtime
After requests to the origin database are stopped, when the clone procedure is initiated, the Neo4j process is stopped, a new database is provisioned and data is copied over.
Database provisioning can take a few seconds for Hobby or Standard databases, and a few minutes for Performance or Enterprise databases. The amount of time it takes to copy over data will mainly depend on your dataset size (a clone operation for a 20GB dataset size will take significantly longer than the same for 500MB of data) . It can also be higher if you are cloning into a different AWS regions since data transfer will be slower.
Neo4j version upgrades will often imply store and/or index migrations. This is most often the case when upgrading through major versions and the amount of time it takes varies depending on the release version and if the are multiple versions ahead of the original one, i.e. upgrading from 2.3 to 3.2 will be generally slower than upgrading from 3.1 to 3.2.
After the clone process and the version upgrade is completed, the database will have different endpoints and a new database user will need to be created in order to connect from your code.
The overall downtime duration will vary depending on the size of your database, the time Neo4j needs to write to disk, any time spent doing the actual Neo4j store and/or index migrations (if any), and the time it takes to create a new user and update the code to point to the new instance and use the new credentials.