Using streamlit as front end to deploy

[dataelvisliang]

When I tested locally with ~600k records, everything worked fine. However, after deploying with Streamlit as the frontend, the app crashes once the dataset size reaches around 280k.

The data is being read from a cloud database that stores pre-computed projections and neighbor information. My understanding is that Embedding Atlas should only be handling the rendering, so I’m wondering if the problem could be related to the input data table format rather than the rendering couldn’t handle the load.

Any suggestions on how I can troubleshoot this?

Thanks!

[domoritz]

Does the front end for backend crash? What's the error? Please provide some code snippets (ideally a fully reproducible example but I see that this might be tricky).

[dataelvisliang]

Thank you for follow up. I checked the log and it seems to be websocket error. I am guessing the data it too large to be loaded to streamlit for processing

[domoritz]

That is odd. I would suggest an issue with Streamlit then.

[donghaoren]

Looks like Streamlit has a maxMessageSize parameter for "Max size, in megabytes, of messages that can be sent via the WebSocket connection". See https://docs.streamlit.io/develop/api-reference/configuration/config.toml.

Let us know if that works for you, if so, we should add a note in the docs.

[dataelvisliang]

Thanks, I tried the message size to be 800 and 2000 but those didn't resolve. The error is saying 'exception=websocketclosedError', adding the exception handling didn't help. I guess this may be the issue with Streamlit not being able to handle large volume of data. Anything else you may suggest me to try?

[donghaoren]

Did the error say something different after you increase the message size?

[dataelvisliang]

Yup, the error is 'tornado.upstream.streamclosederror: steam is closed' and websocketclosedError(), this only happens when the data volume exceeds around 260k

[dataelvisliang]

Does embedding atlas support data chunk loading? Eg., loading data in batches?

[dataelvisliang]

One more question if you don't mind. According to Streamlit’s documentation, the app re-runs on user interactions by default. When I zoom in and out of the Atlas visualization map, this causes noticeable lag due to re-renders (noticed a running man icon on top right of Streamlit UI every time I interact on the map). Do you have any recommendations or best practices for minimizing these automatic re-runs and improving performance when the map is hosted in Streamlit? Thank you!

[donghaoren]

Thanks! The only thing we send back to Streamlit right now is the SQL selection predicate. If you just zoom in on the map it's not supposed to update anything downstream. We'll take a look.

[donghaoren]

Fixing the above in #54

[dataelvisliang]

Thank you!

These are the logs from Streamlit if they help:

2025-09-15 23:58:15.355 Sending cached message ref (hash=MASKED)
2025-09-15 23:58:15.357 Removing orphaned files...
2025-09-15 23:58:15.935 Received the following back message:
rerun_script {
  widget_states {
    widgets {
      id: "MASKED"
      string_array_value {
        data: "2025/08/01"
        data: "2025/08/02"
      }
    }
    widgets {
      id: "MASKED"
      json_value: "{"predicate":null}"
    }
  }
  page_script_hash: "MASKED"
  fragment_id: "MASKED"
  cached_message_hashes: "MASKED"
  context_info {
    timezone: "MASKED"
    timezone_offset: MASKED
    locale: "en-US"
    url: "http://localhost:8501/"
    is_embedded: false
    color_scheme: "light"
  }
}
 
2025-09-15 23:58:15.936 Beginning script thread
2025-09-15 23:58:15.936 Running script RerunData(widget_states=widgets {
  id: "MASKED"
  string_array_value {
    data: "2025/08/01"
    data: "2025/08/02"
  }
}
widgets {
  id: "MASKED"
  json_value: "{"predicate":null}"
}
, page_script_hash='MASKED', fragment_id_queue=['MASKED'], cached_message_hashes={'MASKED'}, context_info=timezone: "MASKED"
timezone_offset: MASKED
locale: "en-US"
url: "http://localhost:8501/"
is_embedded: false
color_scheme: "light"
)
2025-09-15 23:58:16.002 Sending cached message ref (hash=MASKED)
2025-09-15 23:58:16.003 Removing orphaned files...

[dataelvisliang]

Seems like the widget (embedding atlas) is sending the predicate with a null value every time of interaction which makes the Streamlit to rerun

[donghaoren]

Yes, regarding your original issue (the data size limit), have you tried passing something like --server.maxMessageSize=1000, e.g., as below:

streamlit run examples/streamlit.py --server.maxMessageSize=1000

I was able to reproduce the message size limit by making a large data frame, and then setting this option seems to fix it.

[dataelvisliang]

Using the max message size you mentioned in the CLI helped a little (able to load 100k more rows of data) but did not fully resolve the issue yet. I'm now trying to look into the container log and see if it's due to the container config. Thank you