# ODK Central - How to delete a submission

**URL:** <https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609>\
**Category:** Support\
**Tags:** odk-central\
**Created:** [December 10, 2020, 3:40pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609 "2020-12-10T15:40:12Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [August 8, 2024, 4:35pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/22 "2024-08-08T16:35:30Z")

</div>

> [@ktuite](#):
>
> At the moment, there is still no way to delete a submission from Central, but it is on our roadmap. We understand there are issues with the database storage size, especially when using Central as part of a larger data pipeline.

Am I right to say that at this time (August 2024) there is still no way to delete submissions from the Central GUI or odk API? If the answer is "yes" then this is really surprising, I can think at least 3/4 good reasons for that, one of them has been pointed in this thread: to programmatically allow to recoup space on the server where Central runs. A project/form with a few tens of app users sending over data with heavy media (photos/videos) will quickly drain disk space especially on cloud servers. And why I should want to keep them? (Hopefully) the API allows to download submissions + media filtering by date, so it is very reasonable to throw away submissions older than a specific point in time.

At very least I would expect an API call/method to delete/remove media files from submissions...

Anyway... as I guess that there is still no way to delete submissions as one would expect, what would be the **correct** procedure to delete them from within the DB? I can't really afford to mangle the DB/form/central installation and the last time I checked the data model used by Central was all but obvious.

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![Florian\_May](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/florian_may/32/7758_2.png) [@Florian\_May](https://forum.getodk.org/u/Florian_May)\
**Post date:** [October 23, 2024, 4:14am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/23 "2024-10-23T04:14:37Z")

</div>

Hi @manghig,

The API now supports submission deletion: [https://docs.getodk.org/central-api-submission-management/#deleting-a-submission](https://docs.getodk.org/central-api-submission-management/#deleting-a-submission)

[https://docs.getodk.org/central-install-digital-ocean/#using-s3-compatible-storage](https://docs.getodk.org/central-install-digital-ocean/#using-s3-compatible-storage) might solve your storage space constraints.

As for partial downloads, the API definitely supports pagination as well as filtering by e.g. date.  
Both pyODK ([https://getodk.github.io/pyodk/submissions/#pyodk.\_endpoints.submissions.SubmissionService.get\_table](https://getodk.github.io/pyodk/submissions/#pyodk._endpoints.submissions.SubmissionService.get_table)) and  
ruODK support pagination via top/skip and [OData filters](https://docs.ropensci.org/ruODK/reference/odata_submission_get.html#arg-filter) where you can e.g. filter for submission date, see [examples](https://docs.ropensci.org/ruODK/reference/odata_submission_get.html#ref-examples).

Downloading data via `ruODK::odata_submission_get()` doesn't take all that long as it skips already downloaded attachments.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [October 23, 2024, 7:41am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/24 "2024-10-23T07:41:53Z")

</div>

> [@Florian\_May](#):
>
> Hi @manghig,
> 
> The API now supports submission deletion: [https://docs.getodk.org/central-api-submission-management/#deleting-a-submission](https://docs.getodk.org/central-api-submission-management/#deleting-a-submission)

Great news, thanks!

> [@Florian\_May](#):
>
> [https://docs.getodk.org/central-install-digital-ocean/#using-s3-compatible-storage](https://docs.getodk.org/central-install-digital-ocean/#using-s3-compatible-storage) might solve your storage space constraints.

Yes of course, but that is not an option for many.

> [@Florian\_May](#):
>
> As for partial downloads, the API definitely supports pagination as well as filtering by e.g. date.  
> Both pyODK ([https://getodk.github.io/pyodk/submissions/#pyodk.\_endpoints.submissions.SubmissionService.get\_table](https://getodk.github.io/pyodk/submissions/#pyodk._endpoints.submissions.SubmissionService.get_table)) and  
> ruODK support pagination via top/skip and [OData filters](https://docs.ropensci.org/ruODK/reference/odata_submission_get.html#arg-filter) where you can e.g. filter for submission date, see [examples](https://docs.ropensci.org/ruODK/reference/odata_submission_get.html#ref-examples).

Yes I am aware that the API can do that, my whole rant (and I'm sorry for that) in other posts too, is that with briefcase it was also possible without needing to write "complex" scripts: just parameters on a easy to use command line tool (I'm not even taking into account the GUI that was a blessing for many not tech people).

> [@Florian\_May](#):
>
> Downloading data via `ruODK::odata_submission_get()` doesn't take all that long as it skips already downloaded attachments.

Only rust?

regards

---

<div class="post-metadata">

**Author:** ![ktuite](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/ktuite/32/14766_2.png) [@ktuite](https://forum.getodk.org/u/ktuite)\
**Post date:** [October 23, 2024, 4:42pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/25 "2024-10-23T16:42:54Z")

</div>

Hi @manghig, the ability to delete Submissions from the UI in Central is coming soon in the next release! We know this is a highly requested feature and we don't want to limit it to just API users

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [October 24, 2024, 8:37am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/26 "2024-10-24T08:37:49Z")

</div>

That is great news, thanks!  
Would be possible to select \>1 submissions to be deleted?

In general (API or GUI), deleting submissions will recoup disk space when they contain media files? I remember something about PostgreSQL and some extra step to do when deleting records with BLOBs and disk space...

---

<div class="post-metadata">

**Author:** ![seewhy](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/seewhy/32/3199_2.png) [@seewhy](https://forum.getodk.org/u/seewhy)\
**Post date:** [October 25, 2024, 4:46pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/27 "2024-10-25T16:46:08Z")

</div>

MAYBE this answers the question - assuming that the delete submission function works in the same way...

> [@Deleting media from Central submissions - does it reduce database size](https://forum.getodk.org/t/deleting-media-from-central-submissions-does-it-reduce-database-size/47321/2):
>
> Hi @seewhy, For your specific scenario, I believe this should work, though maybe not for the reason you think. It also may take ~24 hrs for you to see the size reduction. This is what will happen under the hood when you DELETE a submission attachment via the API: the data will continue be stored in the database as a blob, but that blob will be unlinked from the submission attachment record. Then a daily cron job for purging deleted forms that have been in the trash for 30 days will do its work …

So it might not be immediate recuperation of space, but once the 'trash' is purged I think that it will be recovered...

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [October 25, 2024, 6:11pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/28 "2024-10-25T18:11:21Z")

</div>

> [@seewhy](#):
>
> So it might not be immediate recuperation of space, but once the 'trash' is purged I think that it will be recovered...

Any idea of how the SQL command looks like? Also some help on how to run it with CRON given that the database is inside docker...

---

<div class="post-metadata">

**Author:** ![seewhy](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/seewhy/32/3199_2.png) [@seewhy](https://forum.getodk.org/u/seewhy)\
**Post date:** [October 25, 2024, 7:11pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/29 "2024-10-25T19:11:07Z")

</div>

Sorry, way beyond my competence - that's under the bonnet / here be dragons kind of stuff. All I know is that there is a CRON that does the necessary compaction of the database when the media 'expires' in the trash (what I'm referring to as a purge) - my guess is that this now takes place as part of deleting the submission (i.e. the submission and its media go to trash). An earlier post in this thread indicated a way of shortening the 'wait time' to purge, but that has a 'with caution' caveat on it...

That was all I needed to know - that it happens, not how to do it manually... I self host, so better for me to push the envelope than throw it on the fire.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [October 26, 2024, 5:52pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/30 "2024-10-26T17:52:45Z")

</div>

So are you saying that it is all automatic? No need to set up that cron job manually?

---

<div class="post-metadata">

**Author:** ![seewhy](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/seewhy/32/3199_2.png) [@seewhy](https://forum.getodk.org/u/seewhy)\
**Post date:** [October 27, 2024, 7:07pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/31 "2024-10-27T19:07:10Z")

</div>

That's my understanding - have a look at the thread that I linked to from @ktuite - it says "a daily cron job for purging deleted forms ... will do its work." and being a little 'retentive' I asked the very same question:

> [@Deleting media from Central submissions - does it reduce database size](https://forum.getodk.org/t/deleting-media-from-central-submissions-does-it-reduce-database-size/47321/4):
>
> The daily cron job that purges long-ago deleted forms is already running, yes. Nothing extra that you need to do!

Not sure if this will help, but here is a basic pyODK script that works for deleting specific attachments, so should be possible to adapt very slightly for the new delete submissions [remove `+'/attachments/'+str(filename)` from the end]... You will need to set up the credentials for pyODK - which are in the [DOCS](https://getodk.github.io/pyodk/#configure).

This would give you the opportunity to loop through a series of submissions and/or attachments in standard python methods - you may be far more skilled with pyODK, so please don't be offended by me offering this:

```auto
from pyodk.client import Client
client = Client()
projectId = [a number]
xmlFormId = 'your_form'
instanceId = 'uuid:...'
filename = 'e.g. epoch_time.jpg'
response = client.delete('/projects/'+str(projectId)+'/forms/'+str(xmlFormId)+'/submissions/'+str(instanceId)+'/attachments/'+str(filename))
print(str(instanceId)+' / '+str(filename)+' status: '+str(response.status_code))

```

(the projectId and xmlformId can be found in Central under the link 'analyse with OData' in the form submissions page)

Also, I don't know how to retrieve attachments that are in Trash - so some caution is required...

Good luck with the deletions and disk space recovery.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [October 28, 2024, 7:40am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/32 "2024-10-28T07:40:30Z")

</div>

> [@seewhy](#):
>
> Good luck with the deletions and disk space recovery.

It should not so so hard to require any luck... It is really a basic feature... and there almost no point to delete submissions with media files if disk spaced is not recovered in an automatic way...

---

<div class="post-metadata">

**Author:** ![seewhy](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/seewhy/32/3199_2.png) [@seewhy](https://forum.getodk.org/u/seewhy)\
**Post date:** [October 28, 2024, 9:39am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/33 "2024-10-28T09:39:59Z")

</div>

The 'luck' is in getting everything right, not how hard it is - if, like me, you have thousands of images to manage and some to delete, you might wish for a little luck that you don't have to come to the forum asking for help to undelete / recover something you did by mistake. And that you'd be lucky enough for someone to answer...

Whilst I might agree that being able to delete submissions should be a core function, I do understand why the ODK team have been cautious in letting something out into the wild that could have devastating consequences to data integrity, possibly in a mission-critical situation (by which I mean life or death, not 'am I going to get into trouble for deleting a spurious image'). Nothing basic about that.

And I would encourage you to read the posts that I linked to before repeating the complaint about automatic disc space recovery - you are turning it into a conspiracy. It **does** happen automatically and it was confirmed unequivocally by a member of the ODK team. That's why I linked to it.

I understand your frustration with this, but please remember that this is open source software - my time is not free, but I might choose to give you it. I could not operate my business as effectively without ODK but I don't pay cash to use it. The least we can do is to contribute something and support its continued development...

---

<div class="post-metadata">

**Author:** ![yanokwa](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/yanokwa/32/1695_2.png) [@yanokwa](https://forum.getodk.org/u/yanokwa)\
**Post date:** [October 28, 2024, 5:18pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/34 "2024-10-28T17:18:18Z")

</div>

As @ktuite noted, when you delete a form or submission in Central, all of its resources and attachments are soft-deleted (put in trash) for 30 days. During those 30 days, you can restore that data. After the 30 days, the data is purged (trash is emptied) and marked in the database as "dead".

PostgreSQL, the database used by Central, automatically [vacuums](https://www.postgresql.org/docs/current/routine-vacuuming.html) up "dead" data and makes it available for re-use. When the autovacuum happens and whether or not it returns space to the operating system (as opposed to only the database) is decided by Postgres based on how it's configured and how you are using it.

Postgres doesn't always return disk space to the operating system because doing so would be an expensive operation and so there is an optimization tradeoff that it makes. True recovery (aka full vacuum or shrinking) by Postgres typically requires blocking reads/writes and twice the size of the database because it's essentially a backup and restore. This is one of the reasons why most cloud databases (e.g., RDS) can't shrink a database once it grows.

If you want to force vacuuming, you can do so:

1. Run `docker exec -it central-postgres14-1 psql -U odk -W odk`
2. Enter the default password: `odk`
3. Run `vacuum`
  - Reclaims space and makes it available for re-use by the database. Does not always return space to the operating system.

4. Run `vacuum full`
  - Reclaims more space, but takes much longer, locks the database so you can't use it, and requires extra disk space. Returns space to the operating system.

So in summary, if you delete data in Central, it eventually frees up space for re-use inside the database, but it may not free up space for re-use by the operating system.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [December 11, 2025, 8:38am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/35 "2025-12-11T08:38:10Z")

</div>

> So in summary, if you delete data in Central, it eventually frees up space for re-use inside the database, but it may not free up space for re-use by the operating system

@yanokwa Hi. If I move the attachments to and S3 compatible storage [https://docs.getodk.org/central-install-digital-ocean/#using-s3-compatible-storage](https://docs.getodk.org/central-install-digital-ocean/#using-s3-compatible-storage) will this trigger freeing disk space on the VPS where Central is now running (and storing the attachments in the PgSQL DB)? Or the `vacuum full` needs to be run manually anyway? Thanks in advance.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [December 11, 2025, 9:51am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/36 "2025-12-11T09:51:00Z")

</div>

@yanokwa follow up question: would this [https://docs.getodk.org/central-api-submission-management/#clearing-a-submission-attachment](https://docs.getodk.org/central-api-submission-management/#clearing-a-submission-attachment) help freeing disk space on the server?

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [December 11, 2025, 12:01pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/37 "2025-12-11T12:01:51Z")

</div>

> follow up question: would this [https://docs.getodk.org/central-api-submission-management/#clearing-a-submission-attachment](https://docs.getodk.org/central-api-submission-management/#clearing-a-submission-attachment) help freeing disk space on the server?

Answering to myself… this by itself does not free any disk space on the server. Did I get wrong that this API call does?

---

<div class="post-metadata">

**Author:** ![yanokwa](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/yanokwa/32/1695_2.png) [@yanokwa](https://forum.getodk.org/u/yanokwa)\
**Post date:** [December 11, 2025, 8:42pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/38 "2025-12-11T20:42:19Z")

</div>

If you want to free up disk space, you need to run `vacuum full` after deleting data or uploading the blobs to block storage. If you don't have 2x the disk space or can't lock the DB for the full vacuum, I've used and recommend [pg\_repack](https://github.com/reorg/pg_repack) as an alternative.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [December 29, 2025, 9:25am UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/39 "2025-12-29T09:25:25Z")

</div>

@yanokwa Hi. I did cleared attachments with [https://docs.getodk.org/central-api-submission-management/#clearing-a-submission-attachment](https://docs.getodk.org/central-api-submission-management/#clearing-a-submission-attachment) now I can see on Central that attachment are missing

![image](https://getodk.b-cdn.net/uploads/default/original/3X/3/c/3c1f6742300fcaabd58c6ff2c0096695a6b89865.png)

I then did the `VACUUM FULL;` operation but after it finished the size of the DB remained unchanged, as seen with

```auto
SELECT pg_size_pretty(pg_database_size('odk')) AS size;

```

before and after clearing attachments with the Central API.

I did another check (before and after) with

`odk=# SELECT relname, relkind, pg_size_pretty(pg_total_relation_size(oid))`  
`FROM pg_class`  
`ORDER BY pg_total_relation_size(oid) DESC`  
`LIMIT 15;`  
`relname | relkind | pg_size_pretty`  
`--------------------------------------+---------+----------------`  
`blobs | r | 116 GB`  
`pg_toast_16560 | t | 116 GB`  
`pg_toast_16560_index | i | 1294 MB`  
`audits | r | 84 MB`  
`client_audits | r | 74 MB`  
`submission_defs | r | 39 MB`  
`client_audits_start_index | i | 13 MB`  
`audits_action_acteeid_loggedat_index | i | 9800 kB`  
`audits_acteeid_loggedat_index | i | 6992 kB`  
`submissions | r | 6160 kB`  
`audits_actorid_action_loggedat_index | i | 6040 kB`  
`form_defs | r | 5240 kB`  
`pg_toast_16915 | t | 5024 kB`  
`form_field_values | r | 4728 kB`  
`submission_attachments | r | 4392 kB`  
`(15 rows)`

As far as I have understood, when UPDATING rows with BLOBs rather then DELETING them (as I assume the “clear submission attachments” API method does):

a new row version is created

the old row version remains in place

the TOASTed BLOB rows referenced by the old row are still there

Is this the correct interpretation? If yes, does this mean that the only way to really shrink the database size is to DELETE submissions with attachments and wait 30 days (other than using a S3 compatible storage)?

thanks in advance

---

<div class="post-metadata">

**Author:** ![ktuite](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/ktuite/32/14766_2.png) [@ktuite](https://forum.getodk.org/u/ktuite)\
**Post date:** [January 20, 2026, 8:14pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/40 "2026-01-20T20:14:05Z")

</div>

I wanted to update a comment I left in [2023](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/19) that said you could manually purge deleted forms/other things by running the following command (er, running with `--help` won't purge anything but will give you more flags, like the `-f` flag, to use):

`docker compose exec service node lib/bin/purge-forms.js --help`

In 2024, we started allowing more things beyond forms to be purged, and wound up renaming that script. The functioning command is (as of Jan 2026):

`docker compose exec service node lib/bin/purge.js --help`

I apologize for that outdated and broken command leading people astray!

This purge command _will_ remove blobs, including "cleared" submission attachments, from the database. I imagine that will make running `vacuum` on the database a lot more effective.

---

<div class="post-metadata">

**Author:** ![manghig](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/manghig/32/11609_2.png) [@manghig](https://forum.getodk.org/u/manghig)\
**Post date:** [January 26, 2026, 6:47pm UTC](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609/41 "2026-01-26T18:47:21Z")

</div>

> [@ktuite](#):
>
> `docker compose exec service node lib/bin/purge.js --help`

@ktuite thanks! this helped A LOT. Together with `VACUUM FULL` I can finally rely on relatively simple workflow to shrink the DB size and recover disk space without needing to remove submissions, just attachments, without the need to wait for the soft delete period to expire.

A couple of suggestions:

1. when the above command is used to purge attachments there is no feedback when it finishes, the message is always like

`"Forms purged: 0, Submissions purged: 0, Entities purged: 0"`

1. add a note about this command in the API docs in the methods to delete submissions/entities/forms/attachments

Regards

[Previous page](https://forum.getodk.org/t/odk-central-how-to-delete-a-submission/31609.md?page=1)
