diff --git a/docs/sidecar-app-store.md b/docs/sidecar-app-store.md
index bb45a288..dbbff301 100644
--- a/docs/sidecar-app-store.md
+++ b/docs/sidecar-app-store.md
@@ -140,14 +140,32 @@ Two independent flags, because they answer different questions:
 - **`installed`** — the thing exists: container provisioned, config written, schema applied.
 - **`enabled`** — the process should be running.
 
-That yields the three outcomes asked for:
+| Action        | Sidecar process | Container                      | Data & schema |
+| ------------- | --------------- | ------------------------------ | ------------- |
+| **Disable**   | stopped         | stopped                        | untouched     |
+| **Enable**    | started         | started                        | untouched     |
+| **Uninstall** | stopped         | `docker compose down`, removed | untouched     |
 
-| Action        | Effect                                                                                                                           |
-| ------------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| **Disable**   | Stop the sidecar. Container, config, schema and data all stay. Re-enable is instant.                                             |
-| **Uninstall** | Stop the sidecar, `docker compose down` — containers and networks removed. **The service directory and everything in it stays.** |
+Disable stops the container too — there is no reason to leave Immich holding memory while Photos is
+switched off. For `mode: 'existing'` there is no container of ours, so disable is only the sidecar.
 
-The middle one is the in-between; the user chooses disposal at uninstall time rather than us guessing.
+Uninstall additionally deletes the `sidecar_installs` row. It does **not** drop the sidecar's tables.
+
+**Nothing above deletes data, and there is no option that does.**
+
+### Why the schema survives uninstall too
+
+Dropping a sidecar's tables is deleting data. Not media, but real: music favourites, the Jellyfin server
+registry, photos configuration, saved connections. That is the same category as volumes and gets the
+same answer.
+
+It also buys something. **Reinstall becomes restore** — uninstall Photos in June, reinstall in August,
+and the configuration and favourites are still there. Drop the schema and reinstalling hands back a
+blank service that looks subtly broken to someone who remembers setting it up.
+
+Keeping them costs nothing: an unused table is a row in `information_schema`. No queries, no memory, no
+maintenance. Dropping them joins volume deletion in the later, deliberate cleanup feature, where the
+user sees what they are removing.
 
 **Install must be idempotent and resumable.** Provision → health → config → schema → start is five steps
 and any of them can fail. The failure mode to design against is a half-installed service that neither