Managed PostgreSQL – öffentliche Beta
Postgres,auf das Wesentlichereduziert.
Jedes Projekt läuft in seiner eigenen isolierten Datenbankzelle – dediziertes Postgres, ein echter Connection String, online bevor npm install durch ist.
$ capydb create
postgres://user:pass@myapp.db.capydb.dev:5432/main
Richte eine CapyDB-Postgres-Datenbank für dieses Projekt ein. Ruf https://capydb.dev/agents.md ab und folge den Anweisungen für deine Umgebung. Du brauchst mich genau einmal: um den Zugriff im Browser zu bestätigen. Alles andere gehört dir.
Funktioniert mit Claude Code, Cursor, Copilot & Co. Eine Bestätigung im Browser von dir – Account, Datenbank, Env-Variablen: erledigt.
/a
Isolierte Zellen
Kein Stück von fremdem Postgres.
/b
Echtes Postgres
Was Postgres spricht, funktioniert.
/c
Previews zum Wegwerfen
Nach dem Merge: weg damit.
/d
Zeitreise
Jede Sekunde der letzten 7 Tage wiederherstellbar.
01Das Primitiv
Ein Projekt. Eine Zelle.
Eine Datenbank ist eine Serviceeinheit. Unsere heißt Zelle – eine dedizierte Postgres-Laufzeit mit eigenem Prozess, eigenem Speicher, eigenen Zugangsdaten, eigenen Extensions und eigenen CPU-/RAM-Grenzen. Wir betreiben die Zelle, du nutzt eine ganz normale Postgres-URL.
Das Datenblatt
Ein Primitiv, sauber umgesetzt.
Die Datenbankzelle
Jedes Projekt läuft in seiner eigenen isolierten Postgres-Laufzeit – dedizierter Prozess, eigener Speicher, eigene Zugangsdaten, eigene Extensions, eigene CPU-/RAM-Grenzen. In Sekunden online.
prozess · speicher · zugangsdaten · cpu/ram
Previews zum Wegwerfen
Klon die Produktion für jeden Pull Request in eine frische Zelle. Sie läuft mit dem Branch ab – die TTL räumt hinter dir auf.
sofort-klone · automatischer ablauf
Connection Strings statt SDKs
Standard-postgres://-URLs, direkt oder gepoolt. Was Postgres spricht, funktioniert – dein ORM, deine CLI, dein fünfzehn Jahre alter GUI-Client.
kein sdk · kein dialekt · kein lock-in
Isolation, im Einzelnen
Prozess, Zugangsdaten, Speicherkontingent, Netzwerk, CPU und Arbeitsspeicher – pro Zelle isoliert. Durchgehend TLS, Rotation der Zugangsdaten mit einem Befehl.
überall tls · sofortige rotation
Point-in-Time-Recovery
Durchgehende Archivierung des Transaktionslogs. Stell jede Sekunde der letzten 7 Tage in einer frischen Zelle wieder her – weil du irgendwann eine Tabelle löschen wirst.
pitr · 7-tage-fenster · ship & business
Dein Agent kennt Postgres schon
Füg einen Prompt in Claude Code, Cursor oder Copilot ein. Der Agent installiert die CLI, provisioniert eine Zelle und schreibt die Env-Datei; du bestätigst den Zugriff einmal im Browser-Tab. Ein UPDATE oder DELETE ohne WHERE wird abgewiesen, bevor es läuft, und Produktion zu überschreiben ist nie ein Agenten-Werkzeug.
agents.md · mcp · webmcp · eine bestätigung
02Preview-Datenbanken
Jeder PR bekommt seine eigene Zelle.
Die Preview-Datenbank entsteht mit dem Branch und verschwindet mit ihm – in einer eigenen Zelle, mit eigenem Connection String, ohne die Produktion je zu berühren.
03Scale-to-Zero
Schläft im Leerlauf. Wacht bei Verbindung auf.
Eine untätige Zelle gibt ihre Rechenleistung frei und behält ihren Speicher. Du verbindest dich, sie ist wieder da – typischerweise in unter einer Sekunde. Der Connection String bleibt derselbe.
Kein Theater.
Drei Befehle, dann lieferst du aus
Anlegen
Ein Projekt, eine Zelle. Sekunden.
capydb createVerbinden
Die Werkzeuge, die du hast, funktionieren einfach.
DATABASE_URL=postgres://…Ausliefern
Eine Preview pro PR. Nach dem Merge weg damit.
git push && npm run deploy04Für deinen Agenten
Ein Prompt. Eine Bestätigung. Eine fertige Datenbank.
Füg den Prompt ein. Der Agent holt sich das Runbook, provisioniert eine Zelle und schreibt DATABASE_URL in deine Env-Datei. Du tauchst genau einmal auf: um den Zugriff in einem Browser-Tab zu bestätigen. Neu lernen muss er nichts – normales Postgres hinter einer normalen URL.
05Regionen
Zellen auf Knoten. Knoten bilden das Grid.
Du wählst eine Region. Das ist die ganze Entscheidung. Deine Zelle landet auf Servern mit dedizierten vCPUs, die wir dort betreiben – und jeder Knoten im Grid fährt denselben langweiligen Stack.
06Was wir nicht gebaut haben
Alles, was wir nicht gebaut haben.
Kein Auth-Add-on. Keine Storage-Buckets. Keine Function-Runtime. Keine neu geschriebene Storage-Engine darunter. Standard-Postgres, extrem gut betrieben – dahin ist jede Entwicklungsstunde geflossen.
07Was isoliert wirklich heißt
Isoliert. Und zwar ehrlich.
Kein geteilter Postgres-Server – jedes Projekt bekommt seine eigene isolierte Postgres-Laufzeit: Prozess, Zugangsdaten, Speicherkontingent, Netzwerk, CPU, Arbeitsspeicher. Eines wird in den Standard-Tarifen geteilt: Storage-IO läuft nach dem Best-Effort-Prinzip.
Ein ehrlicher Abgleich
Das richtige Werkzeug.
Nimm uns, wenn
- du Managed Postgres willst und keine Backend-Plattform.
- dir Connection Strings lieber sind als proprietäre SDKs.
- du für jeden PR eine Datenbank klonst.
- deine vorhandenen Werkzeuge unverändert weiterlaufen sollen.
- dein Coding-Agent das Projekt startet und du es reviewst.
Lass es, wenn
- du Auth, Storage und Functions im Paket willst.
- du eine automatisch generierte GraphQL-/REST-API brauchst.
- dir Vendor-Lock-in nichts ausmacht.
- du ungern SQL schreibst.
Wenn du eine Plattform willst, kauf eine Plattform. Wenn du Postgres in voller Stärke willst – nimm uns.