---
slug: vectors/limits
title: Limits
kind: reference
surface: vectors
summary: Enforced limits of the Aetherfy vector database — per-request caps on search, retrieve, delete and upsert, per-tier request rate, collection and storage caps, the fixed 60-second rate-limit bucket, and per-replica storage accounting.
sources:
  - vectordb:backend/services/rateLimit.js
  - vectordb:backend/services/tierCapabilities.js
  - vectordb:backend/services/storageGauge.js
  - vectordb:backend/utils/responseLimits.js
  - vectordb:backend/utils/collectionValidation.js
  - vectordb:backend/middleware/streamingUpsertPreflight.js
  - vectordb:backend/routes/proxy.js
---

# 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.

| Operation | Cap | Error |
|---|---|---|
| `search` / `scroll` — `limit` | 1 to 1000 | 400 `VALIDATION_ERROR`, with `field` and `max` in the body |
| `points/retrieve` — `ids` | 256 ids | 400 |
| `points/delete` — `points[]` | 512 ids | 400 |
| Payload set / overwrite / delete — `points[]` | 512 ids | 400 |
| `upsert` — point count | 10 000 per call | 400 `TOO_MANY_POINTS` |
| `upsert` — wire body | 500 MB | 413 `PAYLOAD_TOO_LARGE` |
| `upsert` — idle timeout | 30 s with no bytes received | 408 `REQUEST_IDLE_TIMEOUT` |
| Any response body | 10 MB | 413 `RESPONSE_TOO_LARGE`, with `size_mb` and `max_size_mb` |
| Per-point payload | 64 KB | 400 `PAYLOAD_TOO_LARGE` |
| Buffered (non-upsert) request body | 10 MB | 413 |
| Collection name | 1 to 100 characters, `[a-zA-Z0-9_-]` only | 400 |
| Collection description | 500 characters, no HTML angle brackets | 400 |

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:

| Ceiling | What it measures | Error |
|---|---|---|
| 10 000 points | Number of points in one call | 400 `TOO_MANY_POINTS` |
| 500 MB | Bytes on the wire | 413 `PAYLOAD_TOO_LARGE` |
| 30 s idle | Time since the last byte arrived | 408 `REQUEST_IDLE_TIMEOUT` |

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.

| Tier | Requests per minute | Maximum collections | Maximum storage |
|---|---|---|---|
| Free | 1 000 | 3 | 512 MB |
| Starter | 5 000 | 30 | 10 GB |
| Performance | 20 000 | 200 | 200 GB |
| Enterprise | 50 000 | unlimited | unlimited |

Exceeding the collection cap returns 400 `COLLECTION_LIMIT_EXCEEDED`. Plan
details are at [https://aetherfy.com/pricing](https://aetherfy.com/pricing);
current usage is in the Aetherfy dashboard at
[https://app.aetherfy.com/dashboard/billing](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.

| Layout | Counted against your cap |
|---|---|
| 100 GB in one region | 100 GB |
| 33 GB replicated across three regions | 99 GB |

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:

| Expected limit | Reality on Aetherfy |
|---|---|
| Maximum vector dimension | No dimension cap is enforced anywhere in the code |
| Maximum points per collection | No per-collection point-count cap |

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](/vectors/errors).

| Code | HTTP | Cap it enforces |
|---|---|---|
| `VALIDATION_ERROR` | 400 | `limit`, id-array and point-array caps |
| `TOO_MANY_POINTS` | 400 | 10 000 points per upsert |
| `PAYLOAD_TOO_LARGE` | 400 / 413 | 64 KB per-point payload / 500 MB upsert wire body |
| `RESPONSE_TOO_LARGE` | 413 | 10 MB response body |
| `REQUEST_IDLE_TIMEOUT` | 408 | 30 s upsert idle |
| `COLLECTION_LIMIT_EXCEEDED` | 400 | Tier collection count |
| `RATE_LIMIT_EXCEEDED` | 429 | Tier requests per minute |
| `STORAGE_LIMIT_EXCEEDED` | 429 | Tier storage bytes |

## 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.