What the agent actually answered, all 5 times
We are moving off a Postgres instance somebody set up on a virtual machine three years ago and nobody wants to be the one patching it. I want a managed database with backups, a sane connection story for serverless, and branching for our preview environments if possible. Which provider would you use, and what else did you consider?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named neon.com first · 4 of ours named in all
Neon byłby moim wyborem. To zarządzany Postgres zbudowany właśnie pod te trzy wymagania naraz: backupy i point-in-time restore są wbudowane, ma natywny connection pooler (endpoint z PgBouncerem) więc funkcje serverless/Lambda nie zabijają puli połączeń, a branching to ich flagowa funkcja - branch bazy (copy-on-write, sekundy) na każdy PR pod preview environment, nie osobny mechanizm doklejony później. Główny kompromis: scale-to-zero na mniej aktywnych branchach oznacza cold start przy pierwszym zapytaniu, a przy większym ruchu koszt trzeba pilnować, bo model rozliczeń jest inny niż płaski VM.
Co jeszcze brałem pod uwagę:
- **Supabase** - też Postgres z branchingiem, ale branching jest nowszy i płatny od wyższego planu, a produkt dokłada auth/storage/realtime, które są zbędne, jeśli chcecie tylko bazy.
- **AWS RDS / Aurora Serverless v2** - najbardziej dojrzały i sensowny, jeśli już siedzicie w AWS, ale brak natywnego branchingu i połączenia z Lambdy/funkcji serverless wymagają RDS Proxy, czyli dodatkowego elementu do utrzymania - de facto wracacie do tego, od czego uciekacie.
- **PlanetScale** - branching mają dopracowany od lat, ale to dla MySQL; ich oferta Postgres jest świeża i nie ma za sobą tej samej historii.
- **Crunchy Bridge / Render / Railway** - solidny zarządzany Postgres z backupami, ale bez brancingu, więc nie spełniają trzeciego wymagania.
- **CockroachDB** - odpadł od razu, bo to inny model spójności i nie jest to prawdziwa kompatybilność z Postgresem (rozszerzenia, niektóre typy), przerost formy nad potrzebą przy migracji z jednej instancji VM.
Jeśli macie już duży stack na AWS albo wymagania compliance ciągnące was w tamtą stronę, RDS/Aurora byłby bezpieczniejszym wyborem kosztem brancingu. W przeciwnym razie stawiałbym na Neon.
claude · run 2
named neon.com first · 4 of ours named in all
Postawiłbym na **Neon**. Ma natywny branching bazy (kopiuje się przez copy-on-write, więc branch pod PR-a powstaje w sekundy, nie trzeba go ręcznie seedować), oddzielny connection pooler (PgBouncer w trybie transakcyjnym) dla połączeń serverless/edge, autoscaling do zera na czas bezczynności i point-in-time restore w standardzie. To wprost adresuje twoje trzy wymagania: backupy, sensowną historię połączeń dla serverless i branching pod preview environments.
Co jeszcze brałem pod uwagę:
- **Supabase** - też ma branching i backupy, ale to cały framework (auth, storage, realtime) doklejony do Postgresa; jeśli chcecie gołej bazy bez przejmowania reszty stacku, to bagaż, którego nie potrzebujecie.
- **AWS RDS / Aurora Serverless v2** - solidny wybór jeśli już jesteście głęboko w AWS i chcecie jednego dostawcy do wszystkiego, ale zero branchingu z pudełka i "serverless" tu znaczy autoscaling capacity, nie scale-to-zero ani lekki connection story - nadal potrzebujecie RDS Proxy albo PgBouncera osobno.
- **PlanetScale for Postgres** - nowe (branching miały wcześniej tylko dla MySQL), mniej dojrzałe dla Postgresa niż Neon, ostrożnie bym na to teraz stawiał produkcyjnie.
- **CockroachDB / Crunchy Bridge** - mocne pod HA i compliance, ale bez brachingu jako pierwszorzędnej funkcji, więc odpada dla waszego use case'u z preview environments.
Główny kompromis przy Neon: to młodszy gracz niż RDS, więc jeśli macie twarde wymagania compliance/enterprise (SOC2 już mają, ale np. dedykowany VPC peering jest bardziej ograniczony niż w AWS), warto to zweryfikować pod wasze konkretne wymogi zanim zaczniecie migrację.
claude · run 3
named neon.com first · 4 of ours named in all
Neon - branching tam jest natywne (copy-on-write, sekundy, tanie), a pooling pod serverless jest wbudowany w connection string, nie trzeba tego domontowywać. Największy trade-off: to młodszy gracz, więc track record na bardzo dużych obciążeniach jest cieńszy niż przy RDS/Aurora, i tracisz nieco natywnej integracji z resztą stacku jeśli siedzicie głównie w AWS.
Co jeszcze brałem pod uwagę i czemu odpadło:
- **Supabase** - branching już jest, ale to pełny klon projektu, nie copy-on-write, więc wolniejszy i droższy per branch; do tego dostajesz cały dodatkowy platform (auth, storage, realtime), którego możecie nie potrzebować.
- **PlanetScale** - branching to ich rodowód, ale historycznie MySQL-first; oferta Postgres jest nowsza i mniej sprawdzona w boju.
- **AWS RDS / Aurora Serverless v2** - najbardziej sprawdzone, backupy top, ale brak natywnego branchingu i pod serverless trzeba doinstalować RDS Proxy, więcej ręcznej roboty.
- **CockroachDB** - świetny do skali rozproszonej globalnie, ale to przerost formy nad treścią dla was i nie wszędzie w pełni kompatybilny na poziomie protokołu.
Powiedz, jeśli chcesz żebym rozpisał plan migracji z tej maszyny VM na Neon, albo jeśli któryś z odrzuconych ma dla was jednak znaczenie (np. już jesteście mocno w AWS).
claude · run 4
named neon.com first · 3 of ours named in all
Neon - Postgres zbudowany pod dokładnie ten zestaw wymagań: branching baz danych na preview environments to ich flagowa funkcja (branch = copy-on-write, sekundy, nie kopiuje całych danych), connection pooling (PgBouncer wbudowany) rozwiązuje sensownie problem serverless (Lambda/Vercel/Cloudflare Workers bijące w limit połączeń), plus PITR i automatyczne backupy z pudełka.
Co jeszcze brałem pod uwagę:
- **Supabase** - też ma teraz branching i też jest managed Postgres, ale to głównie BaaS (auth, storage, realtime) z bazą jako jednym z elementów; sensowny wybór jeśli i tak chcecie te dodatki, przesada jeśli chcecie tylko bazę.
- **AWS Aurora Serverless v2 / RDS** - najbardziej dojrzałe i "nudne w dobrym sensie", ale brak natywnego branchingu (trzeba by ręcznie snapshotować/klonować) i connection pooling wymaga doklejenia RDS Proxy - więcej ruchomych części do utrzymania, czyli częściowo ten sam problem co teraz.
- **PlanetScale** - dodali Postgres, ale oferta jest nowsza i mniej sprawdzona niż ich MySQL; branching mają, ale zostawiłbym to na później, aż dojrzeje.
Dla migracji z samopisanej VM-ki Neon daje najmniej dodatkowej roboty utrzymaniowej przy pełnym pokryciu wszystkich trzech wymagań na raz.
claude · run 5
named neon.com first · 3 of ours named in all
Neon. To dokładnie w ten worek wymagań: zarządzany Postgres, ciągłe backupy z point-in-time recovery, connection pooling (PgBouncer wbudowany) pod ruch serverless, i branching baz danych 1:1 do naszych preview environmentów (branch = kopia danych, nie tylko schemat).
Co jeszcze brałem pod uwagę:
- **Supabase** - też ma branching i managed Postgres, ale to szerszy pakiet (auth, storage, realtime), którego nie potrzebujemy, a sam branching jest mniej dojrzały niż w Neon.
- **RDS / Aurora Serverless v2** - najbezpieczniejszy wybór jeśli już jesteśmy głęboko w AWS, ale bez natywnego branchingu baz i z droższym, cięższym connection pooling story (RDS Proxy trzeba dokładać osobno).
- **PlanetScale** - dobry branching, ale to MySQL (Vitess), nie Postgres, więc migracja byłaby większa niż migracja "tylko hosta".
- **Railway / Render** - proste i tanie, ale to bardziej "VM z ładniejszym UI" niż faktycznie managed serverless-native Postgres, więc nie rozwiązuje głównego problemu (kto patchuje).
Główny kompromis przy Neon: scale-to-zero i cold starty potrafią dodać opóźnienie przy rzadko używanych branchach, więc branch produkcyjny/staging warto trzymać "always on".
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally