Error: string or blob too big: SQLITE_TOOBIG

[marcoaleixooliveira-tech]

_setStateInternal(state, source = "server") {
    this._state = state;
    this.sql`
    INSERT OR REPLACE INTO cf_agents_state (id, state)
    VALUES (${STATE_ROW_ID}, ${JSON.stringify(state)})
  `;
    this.sql`
    INSERT OR REPLACE INTO cf_agents_state (id, state)
    VALUES (${STATE_WAS_CHANGED}, ${JSON.stringify(true)})
  `;
    this.broadcast(
      JSON.stringify({
        state,
        type: "cf_agent_state"
        /* CF_AGENT_STATE */
      }),

I'm building an application that is heavily based on Agents SDK, but, we are constantly getting this for heavy users.
I know that this is related to the DO key/value limits, but, 2megabytes in 2025 is really hard to manage. A single user long conversation with a LLM will hit that ( with multiple tool call etc ), we are doing heavy optimizations ( we don't store base64, off course, just plan string/arrays ) but wan't to check with you if you have best practices around state, if we might need to migrate to Actors that you recently launched to break down cf_agent_state into multiple tables.

Not sure wdyt, just asking for some ideas :)

[threepointone]

We could automatically split the state string across multiple records for you, we simply didn't get to it yet. Let's use this issue to track making that change.

A problem you'd face (regardless of library) is that incoming websocket messages are limited to 1mb, so that mightbreak syncing

We did (and still want to) want to implement a sync engine that would do patch updates etc, but haven't got to it yet.

A "workaround" here is to implement your own little sync layer and just not use .state on the library, but that's not a super great answer. At least you won't have to migrate away.

I'll sync with the Actors team and align on what we want to do here.

[threepointone]

Btw, I just read again, you shouldn't use .state for chat messages. We have a specialized AIChatAgent class that manages this for you (including with deltas) but can I assume you're not interested in using the ai sdk / useChat? Should our base agent class have a generic reactive messages implementation for chat apps?

[marcoaleixooliveira-tech]

Thanks for quickly replying, saw your message one hour ago and I was studying your docs. Today we use the state to keep hot data ready, like tracking open threads of the user - basic info of the threads and last message, when the user clicks on it, we do our Postgres lookup to get the entire thread history and we basically store everything on our state to keep it warm while the user is interacting. We keep the user Agents in the state, some prompts that the user has and so on.
We write on Postgres just to be able to run some "high level queries" - how many threads the users of this organization has and all of that.

We could automatically split the state string across multiple records for you, we simply didn't get to it yet. Let's use this issue to track making that change.

This really important, right now I'm kind afraid of keeping increasing the responsibility of state on my application and starting to face issues again with this 1mb limitation.

And after reading the AIChatAgent docs it really feels that I was manually doing what you are delivering with it ( that's great! ) - but in the way that it works today, if a thread has like 40 tool call ( with long output's ), do you think that I will face this 1mb limitation or not? I think that my main issue is with tool call output, they are getting longer and longer, today we built a complex logic to offload output of tool calls to R2 and when the user click on the tool call card we fetch from R2 to show to the user - not storing on state anymore, but that's complex to maintain.

And do you plan by any chance do increase this 2mb limit to something bigger? in KV the value has a 25mb limit. I would be very happy with at least 10mb, not sure.