• If you have loaded a lot of data that you then have deleted, your aura instance disk usage may not reflect well in the metrics displayed in the Monitoring tabs.
• This behaviour is normal and results from an optimization of the datastore: nodes ID reuse.
• This means when a node is deleted, it essentially becomes unreferenced, and instead of involving a write operation (that would consume IOPS and involve a system call), it only affects the metadata.
• As a result, the datastore size on disk doesn't shrink accordingly but becomes essentially "uncompacted" with many unused disk data space reserved but not used.    
  See more information on space reuse

Currently, Aura does not offer the compaction feature as standard, you should follow these steps as the current approach for datastore compaction: 
Note: You can also perform the operations through Neo4j Desktop. See How to use Neo4j Desktop to compact your Aura instance's database store? for a step-by-step guide.

1. (on-prem) Set up a Neo4j with the same minor version as Aura (ex Version 2026.03 for 2026.03). We recommend using the Enterprise version to ensure you have access to the essential database administration tools for the next operations. 
2. (Aura) Download a Dump file (Export) from your Aura instance
3. (on-prem) Load the dump file neo4j-admin database load, this will create the store and should require the same disk space as in your Aura instance (ie before disk compaction). See details here
4. (on-prem) Start the database to validate it is imported properly
5. (on-prem) Stop the database 
6. (on-prem) Run 
7.  neo4j-admin database copy --compact-node-store to copy and compact the datastore. See details here
   
   Note that you should consider the following:
   1. All indexes will not be copied, but a file containing the commands to recreate them later is generated. 
   2. Your machine needs a lot of memory and excellent disk performance (see note on IOPS)
   3. If your datastore is large you need to help allocate more memory to process large chunks at a time :
      --to-pagecache=4G
--from-pagecache=16G (as close to as possible to the source datastore size)
   4. Disk space: you will need the original store size + the compacted size (or use different disks/partitions ). 
8. (on-prem) Start the compacted database to validate it starts and that the copy operation worked successfully.
9. (on-prem) Stop the database.
10. (on-prem) Create a Dump file (will be based on compacted data) neo4j-admin dump. See details here.
11. (on-prem) Run neo4j-admin database upload . The size validation that happens on the client side should succeed. See details here
12. (Aura) Once the dump is loaded, go and verify the Metrics -> Storage Used (%) chart and the size change should be reflected (note you may need to select the 6-hour time range to see it reflected)
13. Connect to your AuraDB Instance and run the cypher commands to re-create the indexes based on the output file from Step #6.1.

Cautionary notes

1. Any WRITES performed directly on the Aura instance between the initial export and the final compacted import will be lost.
2. It is best to approach this operation as one that requires downtime.
3. At the very least, only run read queries on the database between the export and import.
4. We cannot estimate the amount of storage that can be reclaimed, as the storage used by a node depends on its properties.
5. Only the neo4j database is compacted. The system database will be untouched, so Roles and Permissions will remain untouched.