#5248Requested

Bandwidth Optimisations

Requested by @xDovos
Energy Committed11,001TeVfrom 4 boosters

currently the bandwidth is one of the more expensive costs of stdb.
part of that is that deleted rows are send as full row even if the PK alone would be enough for the client.
for high update rate tables, this means it is sending almost double the data than it should be.
for row updates, it wouldn't even need the delete row at all as the client can just check if it has the pk in local cache and generate the update callback with just the new insert row.
so in short:

  • deleted rows with PK could just be the PK
  • updated rows with PK could just be the new insert row and no deleted row.
  • rows without PK would still need to be send in full
    but still this would likely cut down the bandwidth by close to 50% with just that small change.
  1. website-features added the feature-request label Jun 7, 2026

Boost this Request

Reopen this request?

The request will return to its prior live status.

Mark as Duplicate

Pick the request that Bandwidth Optimisations is a duplicate of. Energy rolls up into that request and GitHub closes the linked issue as a duplicate with a timeline reference to the canonical.

Unmark Duplicate

Restore as an independent request. The linked GitHub issue will be reopened and its duplicate-of relationship cleared. The original timeline entries stay as history; the note below is posted as a follow-up comment.