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 30 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 30 Tage in einer frischen Zelle wieder her – weil du irgendwann eine Tabelle löschen wirst.
pitr · 30-tage-fenster
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 deploy04Regionen
Zellen auf Knoten. Knoten bilden das Grid.
Du wählst eine Region. Das ist die ganze Entscheidung. Deine Zelle landet auf Hardware, die uns gehört und die wir dort selbst betreiben – und jeder Knoten im Grid fährt denselben langweiligen Stack.
05Was 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.
06Was 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.
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.