Limits
Die Grenzen kennen
Abschnitt betitelt „Die Grenzen kennen“| Bereich | Aktuelle Grenze |
|---|---|
| Workspace-Durchsatz | Jeder Workspace hat einen Writer: sein Durable Object. |
| Retry-Deduplizierung | Ein wiederholter Write wird höchstens einmal angewendet, solange sein Beleg besteht: die halbe Aufbewahrungsdauer, standardmäßig 15 Tage. Ein älterer Retry wird mit retry_expired abgelehnt, statt ein Duplikat zu riskieren. |
| Reads | Keine feste Obergrenze; breite Reads streamen in Keyset-Chunks von 1.000 Zeilen. |
| Bulk-Schreibvorgänge | Beliebig viele Zeilen in einer Transaktion; optimistisch angewendet und offline eingereiht wie jeder Schreibvorgang. |
| Relationen | Relationsfilter und verschachtelte Creates lassen sich ohne Grenze verschachteln, typisiert in jeder Tiefe, und Filter dürfen beliebig lang sein. |
| Live-Fenster | Keine feste Obergrenze; jede geladene Seite bleibt live und wird in Keyset-Blöcken von 1.000 Zeilen gestreamt. |
| Dateizugriff | Pro Datei: role(), fileCheck() oder attachedTo() einer Zeile; der Workspace entscheidet, bevor Bytes bewegt werden. Siehe Dateizugriff. |
| Datei-Uploads | Jede Größe: Über 16 MiB gehen Dateien als R2-Multipart-Upload hoch (Objekte bis 5 TB). Dateibytes liegen in einem separaten R2-Bucket. |
| Presence und Broadcast | Ephemer, über den Workspace-Socket; Socket-Nachrichten jeder Größe (große reisen in Teilen), und ein Socket hält beliebig viele Live-Queries. Broadcast-Nachrichten werden nicht gespeichert oder erneut abgespielt. |
| Aufbewahrung | Gelöschte und überschriebene Werte verschwinden innerhalb der Aufbewahrungsdauer (standardmäßig 30 Tage) aus jeder TapeDB-Kopie. Cloudflare hält unabhängig davon 30 Tage Point-in-Time-Recovery für Durable Objects vor; siehe Datenschutz und Daten. |
| Claim-Route | Standardmäßig begrenzt: 300 Requests pro IP und 30 pro Subject, aufgefüllt über 60 Sekunden; exakt und global. Einstellbar mit identity.limits. |
Die API ist eingefroren; was sich noch ändern kann, steht unter API-Stabilität.