Caching and rate limits

Two settings on a resource protect your database and your bill: caching answers repeated reads from memory, and a rate limit stops one caller from hammering the table.

Response caching

With caching on, Pawabase keeps the answer to a list or get for a number of seconds and serves repeat requests without touching the database. Writes to the table clear its cache automatically. Studio: Settings → Cache responses. 0 turns caching off. Up to a day (86400 seconds).

What is safe to cache

Good	Careful	Don’t
A public catalogue, the same for everyone	Data that differs per user (cached per caller, so safe, but little reuse)	Data that must be exact the instant it changes, like stock levels at checkout

Cache keys include the caller’s identity and the exact query, so one person never receives another’s cached answer. Access rules are still evaluated before a cached response is served.

Clear it

Writes through the API clear the table’s cache. Changes made outside the API (another service writing to the database) don’t; clear the cache yourself from a server:

await manage(pawabase).cache.invalidate({ resources: ["products"] });

pb.manage.cache.invalidate(resources=["products"])

SQL writes through the SQL editor clear the environment’s caches for you.

Browser caching for files

Buckets have their own cache_max_age for stored files. See Storage.

Rate limits

A rate limit allows each caller a number of requests to this table per window. Studio: Settings → Rate limit: Requests and Seconds (the window). Per caller, counted across all gateway instances. A caller is the signed-in user, or the address for anonymous requests. limit is required (the window defaults to 60 seconds). Over the limit, the API answers 429 with a Retry-After header; the client already retries politely and surfaces RateLimitError (retryAfter) if it keeps happening.

try {
  await pawabase.from("search_logs").create({ q });
} catch (e) {
  if (e instanceof RateLimitError) show(`Slow down. Try again in ${e.retryAfter ?? 5}s.`);
}

Which limit applies

There are several layers, from widest to narrowest:

Who may call your API at all: allowed websites and server addresses, and each key’s own address and route limits (see Environment settings and API keys).
Your plan’s request limits (see Usage & plan in Studio).
This resource’s limit.
Authentication’s own limits on sign-in and sign-up.

A request must pass all of them. Use the resource limit for tables that are expensive or abusable (search, exports, anything that sends email).

Choosing numbers

Table	Suggested
Normal CRUD	No limit; rely on the plan
Writes that trigger work (orders, messages)	30 to 120 per minute per caller
Search or heavy lists	30 per minute per caller
Public sign-up forms	Auth’s own limits, plus a resource limit on the table

API keys

Limit a key by address and route.

Table settings

Where they live.

Getting started

Define your data

Change safely

Read and write

Protect and shape

Studio tools

Build well

Caching and rate limits

Response caching

What is safe to cache

Clear it

Browser caching for files

Rate limits

Which limit applies

Choosing numbers

API keys

Table settings

​Response caching

​What is safe to cache

​Clear it

​Browser caching for files

​Rate limits

​Which limit applies

​Choosing numbers

API keys

Table settings

Response caching

What is safe to cache

Clear it

Browser caching for files

Rate limits

Which limit applies

Choosing numbers