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 und Linting. Ein UPDATE oder DELETE ohne WHERE wird vor der Ausführung angehalten, mit einem Wiederherstellungspunkt einen Klick entfernt, und jeder Schreibzugriff wird von dir bestätigt.

Einrichtung durch einen Agenten

Ein Prompt schickt Claude Code, Cursor oder Copilot zu einem gehosteten Runbook, das die CLI installiert, eine Zelle provisioniert und die Env-Datei schreibt. Du bestätigst den Zugriff einmal im Browser-Tab.

MCP-Server

Ein Server, lokal über stdio oder remote über HTTP, der dieselbe API aufruft wie das Dashboard: Projekte, Verbindungen, SQL, Schema, Previews, Backups, Wiederherstellungspunkte, Importe und den Workspace.

Browser-Werkzeuge

Das Dashboard registriert Werkzeuge für einen Agenten in einem WebMCP-fähigen Browser – in der Sitzung, in der du bereits angemeldet bist. Kein Schlüssel, kein Server, und jeder Schreibzugriff wartet hinter einem Dialog.

Sicherheitsschleife für Agenten

Ungezielte Schreibzugriffe werden abgewiesen, bevor sie laufen: ein UPDATE oder DELETE ohne WHERE oder ein TRUNCATE. Eine misslungene Änderung wird in eine Preview wiederhergestellt, nie über Produktion. Produktion zu überschreiben ist auf keiner Oberfläche ein Agenten-Werkzeug.

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 Datenbank steht, in ihrer Region.

Clients, die du schon nutzt

Das Upstash-REST-Protokoll und RESP, beide unterstützt. @upstash/redis funktioniert über REST mit seinen Standardeinstellungen; Redis-Clients verbinden sich über TLS und senden den Hostnamen als TLS-Servernamen (SNI) – redis-py und go-redis tun das von selbst, ioredis und redis-cli brauchen eine Einstellung. 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 etwa einer Drittelsekunde.