Many Apigee Analytics Services tasks can be performed using standard Postgres utilities. The
routine maintenance tasks you would perform on the Analytics database---such as database
reorganization using VACUUM, reindexing and log file maintenance---are the same as those you
would perform on any PostgreSQL database. Information on routine Postgres maintenance can be
found at
[http://www.postgresql.org/docs/9.1/static/maintenance.html](https://www.postgresql.org/docs/9.1/static/maintenance.html).

> [!NOTE]
> **NOTE:** Postgres autovacuum is enabled by default, so you do not have to explicitly run the VACUUM command. Autovacuum reclaims storage by removing obsolete data from the PostgreSQL database.

> [!NOTE]
> **NOTE:** Apigee does not recommend moving the PostgreSQL database without contacting Apigee Customer Success. The Apigee system uses the PostgreSQL database server's IP address. As a result, moving the database or changing its IP address without performing corresponding updates on the Apigee environment metadata will cause undesirable results.

For more on maintaining PostgreSQL database, see
[http://www.postgresql.org/docs/9.1/static/maintenance.html](https://www.postgresql.org/docs/9.1/static/maintenance.html).

> [!NOTE]
> **NOTE:** No pruning is required for Cassandra. Expired tokens are automatically purged after 180 days.

## Pruning Analytics Data

As the amount of analytics data available within the Apigee repository increases, you may find
it desirable to "prune" the data beyond your required retention interval. Run the following
command to prune data for a specific organization and environment:

```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql pg-data-purge org_name env_name number_of_days_to_retain
```

To run the script, enter the following command:

```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql pg-data-purge org_name env_name number_of_days_to_retain [Delete-from-parent-fact - N/Y] [Confirm-delete-from-parent-fact - N/Y]
```

The script has the following options:

- `Delete-from-parent-fact` Default : No. Will also delete data older than retention days from parent fact table.
- `Skip-confirmation-prompt`. Default: No. If No, the script will prompt for confirmation before deleting data from parent fact. Set to Yes if the purge script is automated.

This command interrogates the "childfactables" table in the "analytics" schema to determine
which raw data partitions cover the dates for which data pruning is to be performed, then drops
those tables. Once the tables are dropped, the entries in "childfactables" related to those
partitions are deleted.

Childfactables are daily-partitioned fact data. Every day new partitions are created and data
gets ingested into the daily partitioned tables. So at a later point in time, when the old fact
data will not be required, you can purge the respective childfactables.

The script has the following options since version 4.51.00.00:

- Delete-from-parent-fact Default : No. Will also delete data older than retention days from parent fact table.
- Confirm-delete-from-parent-fact. Default: No. If No, the script will prompt for confirmation before deleting data from parent fact. Set to Yes if the purge script is automated.

> [!NOTE]
> **NOTE:** If you have configured master-standby replication between Postgres servers, then you only need to run this script on the Postgres master.

## Purge aggregate table data

Aggregate tables typically don't consume as much space as fact tables. However, if you want to
purge old data from aggregate tables, run the following command:

```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql agg-data-purge org_name env_name days_to_retain [confirm_data_deletion-Y/N]
```

where `confirm_data_deletion` is an optional parameter to prompt for confirmation.
The default value is `N`.

> [!NOTE]
> **Note:** Unlike pruning of fact data, in which child fact tables are
> dropped and the disk space consumed by the table immediately released back to the operating system,
> when purging aggregate table data, disk space may not be released back to the operating system.
> Instead, the disk space available after deleting older aggregate data is made available for the
> same table for future use.
>
> If you want to free up disk space for the operating system, you may need to run
> [`VACUUM FULL`](https://www.postgresql.org/docs/14/sql-vacuum.html)
> on the relevant tables. Note that running `VACUUM FULL` on a table exclusively locks
> the table and may require as much additional free disk space as the original table occupied
> before `VACUUM FULL` was run.