Billing and limits concepts

Tinybird plans are sized and billed according to available resources and usage, with limits that you can exceed temporarily.

Read on to understand the key concepts behind your bill and plan limits.

Active vCPU minutes / hours

Developer plans bill vCPU usage using active minutes. An active minute is when any operation used a vCPU for a minute. Multiple operations executed within the same minute still count as a single active minute. When using fractioned vCPUs, an active minute is proportional to the fraction, for example 30 seconds of 0.5 vCPU.

Plan sizes come with a number of active hours, which is the number of active minutes you can use divided by 60. If you consume all your active minutes, the overage is billed at a fixed rate per minute. Usage bursts allows you to temporarily exceed the vCPU usage limit. See Burst mode.

Queries per second

Queries per second (QPS) is the maximum number of queries per second that your plan allows. Calls to API endpoints and queries sent to the Query API count towards your QPS limit. Queries made from the UI are excluded from the limit.

Plan sizes come with a number of QPS, which is the maximum number of queries per second that your plan allows. If exceed the QPS limit, your QPS are temporarily reduced for a fixed amount of time. Usage bursts allows you to temporarily exceed the QPS limit. See Burst mode.

Burst mode

To allow for unexpected spikes in traffic, each plan includes a burst mode. Burst mode allows you to temporarily exceed your vCPU and QPS limits. If you temporarily exceed your limits, you won't be billed and you'll receive an email alerting you of the situation and suggesting to increase your plan size.

vCPU burst mode

Your operations can take x2 vCPU time per minute allowed in you plan for real-time operations. For batch operations, like populates or copies, we allow the whole operation to run until it reaches a platform limit, like maximum available memory.

For example, for a populate that needs 180 seconds of CPU time in a minute, if you are on a Developer Plan S-1 where we allow operations to run up to 120 seconds per minute, the operation will finish and the limit won't be triggered.

QPS burst mode

Your operations can take x2 QPS per second allowed in you plan for API endpoint requests or SQL queries.

To better understand how burst mode works, consider the following example:

  • You’re on a plan with a standard rate of 10 QPS and a burst capacity of 20 QPS.
  • Your plan allows 10 queries per second as the normal rate (leak rate).
  • You have a burst capacity of 20 QPS, meaning you can temporarily handle up to 20 queries per second for short bursts.
  • Each second, your bucket can "leak" 10 queries and can temporarily hold more if needed.

Here's how burst mode works in practice:

  • If you send 15 queries in one second, 10 are processed at the normal rate and 5 use burst capacity.
  • If you send 25 queries in one second, 10 are processed at normal rate, 10 use burst capacity, and 5 are rejected (over the 20 QPS burst limit).
  • The burst capacity "leaks" back to normal levels at a rate of 10 QPS, meaning after a burst, your capacity gradually returns to the standard rate.

The leaking mechanism ensures you can handle occasional traffic spikes while maintaining overall performance and preventing system overload.

For example, if you use your full burst capacity of 20 QPS, it takes about 1 second of processing at the normal 10 QPS rate before you can burst again. This helps balance flexibility for traffic spikes with consistent system performance.

Next steps

Updated