Limits in the Aetherfy vector database

Per-request caps in the Aetherfy vector API

These caps are enforced in Aetherfy’s code on every request, on every tier. They do not scale with your plan.

Every one of these is a hard refusal from Aetherfy, not a truncation. A search asking for 5000 results does not silently return 1000 — it returns 400.

How Aetherfy caps an upsert

Upserts to the Aetherfy vector database are streamed, which means there is no buffered body-size cap in the ordinary sense. Three separate ceilings apply instead, and they measure different things:

The 10 000-point cap is a request-level ceiling on count, not on size. A batch of 10 001 tiny points is refused; a batch of 9 999 large ones is not — it will instead be judged against the 500 MB wire ceiling. Split large loads into batches sized by point count first, and check the byte size second.

The idle timeout is measured against silence, not total duration. A slow but continuously-transmitting upload does not trip it; a stalled connection does.

Per-tier caps in the Aetherfy vector database

These caps come from your plan. The request rate is per minute; storage is counted as described in the storage section below.

Exceeding the collection cap returns 400 COLLECTION_LIMIT_EXCEEDED. Plan details are at https://aetherfy.com/pricing ; current usage is in the Aetherfy dashboard at https://app.aetherfy.com/dashboard/billing .

Note that Free and Starter are single-region plans — the region is fixed by the first resource created — and multi-region replication begins at the tier named Performance. That distinction interacts directly with the storage cap.

Rate limiting in the Aetherfy vector database

Aetherfy meters requests in a fixed 60-second bucket, not a sliding window. The counter resets at the bucket boundary; it does not decay continuously. A burst that fills the bucket early leaves the rest of that minute refused, and the full allowance returns at the boundary rather than trickling back.

Exceeding the allowance returns HTTP 429 with error.code set to RATE_LIMIT_EXCEEDED.

There is no Retry-After header on an Aetherfy 429. Do not write a client that waits for one — it will not arrive. Back off on your own schedule.

How Aetherfy counts storage

max_storage_bytes counts every replica. Storage is measured as bytes stored, summed across the regions holding your data — not as the logical size of your data set.

This is why the tier that unlocks replication also raises the storage cap: replication multiplies the number, and on a multi-region plan a collection consumes its bytes once per region that holds it.

When you exceed the cap, Aetherfy refuses writes with 429 STORAGE_LIMIT_EXCEEDED. Reads are never blocked. A collection over its storage cap is still fully searchable; you simply cannot add to it until space is freed.

One detail about the crossing itself: the batch that takes you over the threshold is allowed through. Aetherfy refuses subsequent writes, so you will observe the limit as a rejection after the fact, not as a partially-applied batch.

Vector dimensions and point counts in the Aetherfy vector database

Two limits people expect to find here do not exist:

What is enforced at the collection level is storage bytes and the collection count from your tier — nothing else. A collection’s practical size ceiling is therefore your storage cap, reached through however many points and however many dimensions get you there.

Error codes attached to Aetherfy limits

Every cap on this page surfaces as one of these codes. Full definitions, including which are retryable, are on errors.

Frequently asked questions about Aetherfy limits

Does storage count once, or once per region?

Once per replica. Aetherfy’s max_storage_bytes is measured across every region that holds a copy of your data, so a 33 GB collection replicated to three regions consumes 99 GB of your cap — the same as 99 GB sitting in a single region. This only affects plans that replicate: Free and Starter are single-region, so on those tiers stored bytes and counted bytes are the same number.

What happens if I exceed my storage cap?

Writes are refused with 429 STORAGE_LIMIT_EXCEEDED; reads are never blocked. An Aetherfy collection over its cap remains fully searchable and retrievable — only the write path closes. Note also that the batch which crosses the threshold is allowed to complete, so the first error you see arrives on the write after the one that put you over. To recover, delete points or collections, or move to a tier with a larger cap.

Why is my upsert rejected at 10 000 points when there is no body-size limit?

Because the two are different ceilings. The 10 000 figure is a per-call cap on the number of points in the request, enforced by Aetherfy before the data is processed; it says nothing about bytes. Upserts stream, so there is no ordinary buffered body limit — but there is still a 500 MB wire ceiling that returns 413 PAYLOAD_TOO_LARGE. A batch can therefore be refused for having too many points while being nowhere near any size limit, and vice versa. Batch by point count first.

Is there a Retry-After header on an Aetherfy 429?

No. Aetherfy does not send Retry-After on a 429, on either RATE_LIMIT_EXCEEDED or STORAGE_LIMIT_EXCEEDED. Clients must implement their own backoff. Since the rate-limit bucket is a fixed 60-second window, waiting for the next boundary is a sound strategy for RATE_LIMIT_EXCEEDED; for STORAGE_LIMIT_EXCEEDED, waiting achieves nothing, because nothing frees itself — you have to delete data or raise the cap.

Is the Aetherfy rate-limit window sliding?

No — it is a fixed 60-second bucket. The count resets wholesale at each boundary rather than ageing out request by request. Practically, this means a client that spends its entire minute’s allowance in the first second is refused for the rest of that minute and then has the full allowance again, and that smoothing your request rate across the minute is what keeps you under the cap.