Invantive Cloud is a shared environment, so one subscription retrieving without restraint would slow the service for everyone on it. Daily limits keep that from happening. They apply only to Invantive Cloud; an on-premises product such as [[Invantive Data Hub/Invantive Data Hub|Invantive Data Hub]] retrieves against the platform directly and is not bound by them. ## What Is Counted Each measure is counted twice: once for data retrieved fresh from the platform, and once for all data, which includes what came from the cache. - the number of rows retrieved from the connected platforms; - the number of rows processed by the SQL engine; - the volume of data exchanged; - the number of requests; - the total duration of the requests. Counting fresh and cached separately matters because a repeated retrieval served from the cache costs the platform nothing while it still costs the service something. It also means that caching is the cheapest way to stay within the limits. The limits were set against actual daily use, so ordinary work does not meet them. ## When a Limit Is Reached A request beyond a limit is answered with `429 Too Many Requests`. The request is refused; nothing is half-executed. A 429 is not by itself a sign of anything being wrong with the query. It says that the subscription has used its allowance for the day, which can equally be the result of one heavy report as of many small ones. ## Seeing the Consumption The usage against the limits is shown with the licence usage statistics on the home page of Invantive Cloud. [[Invantive Bridge Online/Invantive Bridge Online|Invantive Bridge Online]] additionally returns the figures in HTTP headers on every response, so a client can watch its own consumption without opening the interface; see [[Invantive Bridge Online/Fair Use Limits|Fair Use Limits]] there. ## Staying Within Them The remedy is nearly always to retrieve less rather than to retrieve again: - select the columns actually used instead of every column of a table; - filter at the source, so the platform sends fewer rows; - rely on the cache between full retrievals rather than refreshing everything on a schedule; - avoid several parallel retrievals against the same platform, which divide the available speed between them. Where the volume is genuinely needed every day, the answer is a subscription which covers it, or moving the work to an on-premises product where the limits do not apply.