# Session data limits? **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [August 28, 2025, 12:49am UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229 "2025-08-28T00:49:29Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jrd](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@jrd](https://forum.inductiveautomation.com/u/jrd)\ **Post date:** [August 28, 2025, 12:49am UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229/1 "2025-08-28T00:49:29Z")
In Perspective I have a custom variable “model“ that is a dict of (currently) 34 items, each of which is a variable pulling model data from sql. I want/need these data to be available in the session. IMO it is not a huge amount of data being queried. However it seems I have hit some kind of limit. If I add more elements to this model object, the sql does not execute and the variable returns ‘null’ Is there a limit on how much data can be queried? limit on number of such queries? Is there a setting I can change? Thanks ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 28, 2025, 1:20am UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229/2 "2025-08-28T01:20:31Z")
- Perspective has to JSONify any objects you assign to Perspective session/view/component properties. - Each assignment will, for any variables that aren't marked private, generate a message to the browser with the munged content. If that message is too large, there will be an error and the assignment will fail. Not sure what is going on for you, as I am not a mind reader, and you have shared no code of any kind. 🤷‍♂️ ---
**Author:** ![jrd](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@jrd](https://forum.inductiveautomation.com/u/jrd)\ **Post date:** [August 28, 2025, 2:24am UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229/3 "2025-08-28T02:24:34Z")
No code of any kind to share! What’s going on is: I defined a session.custom object named ‘model‘ Within this object I have created member variables, which are mostly lists. These all have query bindings to tables in a mysql database There are currently 34 such member variables, and growing. I need to add more When I add additional variables they do not update, ie it seems the query binding on the additional variables do not execute Of the 34 existing variables, only 32 get values from the database. The other 2 return null. I figure there is a limit (somewhere) of 32. So what to do? Create an object called model\_part\_2? Most annoying Any additional info you require? Regards ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [August 28, 2025, 3:00am UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229/4 "2025-08-28T03:00:24Z")
If you open one of the two+ failed bindings within Designer, are the queries executed successfully there? > [@jrd](#): > > These all have query bindings to tables in a mysql database If possible, I recommend you create and execute a single query which requests data for all 34+ groups of data, then (perform any post-processing needed and) return the results in the format your app requires. There are limits to number of simultaneous database connections. Excessive queries, combined with lengthy query times and timeout limits may be contributing to your observations at runtime. > [@jrd](#): > > No code of any kind to share! For starters, how about posting formatted code for one of your queries, provide the size of your results set for that query, how the queries differ between bindings, and a screenshot (or copy the object and paste the formatted code) of your resultant object? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 28, 2025, 12:48pm UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229/5 "2025-08-28T12:48:51Z")
> [@jrd](#): > > I defined a session.custom object named ‘model‘ Make it private. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 28, 2025, 2:43pm UTC](https://forum.inductiveautomation.com/t/session-data-limits/110229/6 "2025-08-28T14:43:37Z")
> [@jrd](#): > > I figure there is a limit (somewhere) of 32. I can guarantee you there's no explicit limit anywhere in code of the number of elements in a Perspective 'object' type property - or rather, if there is, it's a fundamental Java collection limitation that will be a power of 2 (minus one) like 2,147,483,647, **not** 32. It is _possible_, depending on the depth of the data _within_ those 32 keys, that what you're encountering is an issue with the backing Websocket between the Perspective "backend" (on the gateway) and the "frontend" (wherever the session is actually running) synchronizing property values. This websocket is deliberately set out of the box to a relatively low size (still _megabytes_) so that someone writing a script that sends huge volumes of data will have to deliberately raise this limit, rather than have it cause performance issues for their entire gateway. If this _is_ what's happening, it should be explicitly clear from your gateway logs - it's not a 'quiet' failure condition. As Phil mentioned - the simplest solution (if these are _custom_ properties, which almost by definition can only be interacted with from the backend) is to mark the entire root property as 'private'. This prevents us from synchronizing it to the frontend entirely, work which is basically guaranteed to be pointless for custom properties which can only be reached by scripts/expressions/bindings that are evaluating on the backend anyways.