Funktionen

Isolierte Datenbankzellen

Ein eigener PostgreSQL-Prozess pro Projekt, mit eigenem Speicher, eigenen Zugangsdaten und eigenen CPU- und Speichergrenzen. Kein Schema in einer geteilten Datenbank.

Direkte und gepoolte Verbindungen

Eine normale postgres://-URL auf dem Direktport und ein Transaktionspooler auf dem Poolport für Serverless- und Edge-Laufzeiten. Dieselbe Datenbank, zwei Türen.

Extensions

Ein kuratierter Katalog, den du pro Zelle aktivierst und der in der Datenbank aktuell gehalten wird, statt hinter der Paketversion zurückzufallen.

Isolation und Sicherheit

Privater Netzwerk-Namespace, kein ausgehender Verkehr aus Standardzellen, SCRAM durchgereicht statt gehalten, API-Schlüssel nur als Hash gespeichert.

Preview-Datenbanken

Eine vollständige Kopie deiner Datenbank, geklont statt gedumpt, mit Ablaufzeit. Eine pro Pull Request, abgeräumt beim Merge.

Importe und Migrationen

Hol dir eine Datenbank von einem anderen Anbieter oder deinem eigenen Server – mit einem Follow-Modus, der bis zum Umschalten synchron bleibt.

Schema-Werkzeuge und Typgenerierung

Schema aus der CLI dumpen und vergleichen und aus der laufenden Datenbank TypeScript-Typen, Zod-Schemas oder Drizzle-Definitionen erzeugen.

Studio

Ein SQL-Editor im Dashboard mit Schema-Browser, Linting und einem Wiederherstellungspunkt vor jeder destruktiven Ausführung.

K/V-Speicher

Ein Key-Value-Speicher in einer eigenen isolierten Zelle, in derselben Region wie deine Datenbank. Nutze ihn für Rate Limiting, Sessions, Queues und Caching – oder für sich allein, ganz ohne Datenbank.

Rate Limiting

Sliding-Window-, Fixed-Window- und Token-Bucket-Limiter über @upstash/ratelimit, geprüft gegen einen Speicher, der neben deiner Anwendung steht statt einen Ozean entfernt.

Clients, die du schon nutzt

Das Upstash-REST-Protokoll und RESP, beide unterstützt. @upstash/redis, ioredis, redis-py und redis-cli verbinden sich unverändert – es gibt keinen CapyDB-Client, den du übernehmen müsstest.

Backups und Point-in-Time-Recovery

Laufende Archivierung außerhalb des Knotens mit Wiederherstellung auf jeden Moment im Aufbewahrungsfenster, plus geplante Prüfung, dass die Wiederherstellung wirklich funktioniert.

Observability

Ressourcennutzung, Verbindungszahlen und Abfragedetails pro Zelle, mit Alarmen auf die Bedingungen, die einem Ausfall tatsächlich vorausgehen.

Alarme

Benachrichtigungen zu den Bedingungen, die einem Ausfall tatsächlich vorausgehen – Speicherdruck, veraltete Backups, ausgelastete Verbindungen – per E-Mail oder an deinen eigenen Webhook.

Pause bei Leerlauf

Eine unberührte Zelle schläft ein und beansprucht ihren Anteil am Knoten nicht mehr. Die nächste Verbindung weckt sie, typischerweise in weniger als einer Viertelsekunde.