A container's root filesystem is its image's read-only layers plus one thin writable layer on top (Overlay Filesystems). Every file the container creates or changes lands in that layer, and docker rm deletes it:
docker run --name l3-eph alpine:3 sh -c 'echo "order 1001" > /tmp/order.txt'
docker diff l3-eph
docker rm l3-eph >/dev/null
docker run --rm alpine:3 cat /tmp/order.txtC /tmp A /tmp/order.txt cat: can't open '/tmp/order.txt': No such file or directory
docker diff lists the writable layer's contents: A added, C changed, D deleted. The new container started from the same image with a fresh, empty layer. That is exactly what you want for an application: every start is clean, and an image can be replaced by a newer one at any time. It is exactly wrong for a database. The writable layer is also slow for heavy writes, because the overlay filesystem copies a whole file up from the image the first time it changes. Data that must outlive a container, or that is written heavily, belongs on a mount.