Container Registry: add metadata database beta section

doc/administration/packages/container_registry.md

@@ -1252,6 +1252,16 @@ itself on the system so that the `gitlab-ctl` command can bring the registry ser
 Also, there's no way to save progress or results during the mark phase of the process. Only once
 blobs start being deleted is anything permanent done.
 
+### Continuous Zero Downtime Garbage Collection **(BETA)**
+
+You can run garbage collection in the background without the need to schedule it or require read-only mode,
+if you migrate to the [metadata database (beta)](#use-a-postgresql-database-for-metadata).
+
+NOTE:
+If you would like to try this [beta feature](../../policy/experiment-beta-support.md#beta),
+you should review the [known limitations](#known-limitations). If you have any feedback,
+you can let us know in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423459).
+
 ## Configure GitLab and Registry to run on separate nodes (Linux package installations)
 
 By default, package assumes that both services are running on the same node.
@@ -1353,6 +1363,43 @@ including all the supported storage backends. To migrate to the GitLab Container
 you can follow the instructions on this page, and use the same storage backend as the Distribution Registry.
 The GitLab Container Registry should accept the same configuration that you are using for the Distribution Registry.
 
+## Use a PostgreSQL database for metadata **(BETA)**
+
+WARNING:
+The metadata database is in early beta for self-managed GitLab instances.
+
+By default, the container registry uses object storage to persist metadata
+related to container images. This method to store metadata limits how efficiently
+the data can be accessed, especially data spanning multiple images, such as when listing tags.
+By using a database to store this data, many new features are possible, including
+[online garbage collection](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/db/online-garbage-collection.md)
+which removes old data automatically with zero downtime.
+
+This database works in conjunction with the object storage already used by the registry, but does not replace object storage.
+You must continue to maintain an object storage solution even after migrating to a metadata database.
+
+The metadata database is already in use on GitLab.com, and is now available as a beta feature
+for self-managed GitLab instances.
+
+### Known Limitations
+
+- No support for online migrations.
+- Geo Support is not confirmed.
+- Registry database migrations must be ran manually when upgrading versions.
+
+### Migration Instructions and Feedback
+
+Instructions on how to migrate to the database may be found in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423459) for the beta period.
+This issue also serves as a place to report issues and to get an overview of the beta status.
+
+### Metadata database feature support
+
+You can migrate existing registries to the metadata database, and use online garbage collection.
+
+Some database-enabled features are only enabled for GitLab.com and automatic database provisioning for
+the registry database is not available. Review the feature support table in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423459#supported-feature-status)
+for the status of features related to the container registry database.
+
 ## Troubleshooting
 
 Before diving in to the following sections, here's some basic troubleshooting: