Scalability limits of OMERO (large datasets ~500TB) and channel handling limitations for high-dimensional images (100+ channels)

[ZYsAccount]

We are currently deploying OMERO in a large-scale spatial proteomics / multiplex imaging environment and evaluating its suitability as a long-term data management and visualization platform.

During our testing with OMERO (Docker-based deployment), we encountered two important questions that are not clearly addressed in the current documentation.

We would greatly appreciate clarification from the development team.

1. Data scale / system limits (~500TB)

We are planning to manage very large imaging datasets, potentially reaching hundreds of terabytes (~500TB total storage).

We would like to understand:

Is there any practical or architectural limit for OMERO in total managed dataset size?
Would OMERO remain stable and performant at ~500TB scale?
Are there known bottlenecks in:
OMERO.server performance under large metadata load
PostgreSQL scalability (number of images / datasets)
ManagedRepository / Pixels storage layer
Web viewer or API performance at large scale
Are there recommended best practices for such scale, e.g.:
multiple OMERO servers
distributed storage backend
database tuning strategies

Any guidance or real-world deployment experience at this scale would be very helpful.

2. Channel number limitation (high-dimensional imaging)

We are working with highly multiplexed imaging data.

We successfully imported a pyramidal OME-TIFF containing 184 channels.

Observations:
Import completes successfully without errors
Image is accessible in OMERO
However, OMERO.web / iviewer does not allow practical visualization of all channels
Channel rendering becomes unusable / incomplete in UI

3. Environment
   openmicroscopy/omero-server:5
   openmicroscopy/omero-web-standalone:5

[will-moore]

A few immediate points, but I'll ask others for more details since I'm not a sysadmin...

1. OMERO is used for https://idr.openmicroscopy.org/ which is run by the OME team. It has comparable numbers to your use-case. See https://idr.openmicroscopy.org/about/deployment.html for some details, but this is designed to handle public access (potentially high access loads).
   The most resource-intensive operation for most OMERO deployments is image import, since a lot of database updates are happening. We also found "search" type queries (using omero-mapr to query Key-Value pair annotations across all images in the DB) to be a limiting factor as the Database got larger. We have since moved to using an elasticsearch based solution.
   Other performance (web, api etc) doesn't seem to suffer as OMERO scales.

2. We currently limit omero-iviewer to viewing 10 channels at once (this is configurable). What does "practical visualization of all channels" mean? Is it really possible to view an image and distinguish more than a handful of channels at once? Or is it the ability to group channels into collections that you can turn on/off together at once?

[will-moore]

The image.sc forum is a good place to ask the community. E.g. see https://forum.image.sc/search?q=omero%20at%20scale
finds a bunch of relevant topics, including https://forum.image.sc/t/omero-production-server-current-best-practices/71074/6