Mentionsy
Z życia Protopii - gdzie hostować postgresa?
„Usługa odrzucona i bardzo dobrze - cieszymy się z tego bardzo mocno.” Szymon opisuje analizę PostgreSQL hosting dla dziesiątek terabajtów danych. Odrzucili Cosmos DB for PostgreSQL jako „świetny na papierze, ale tylko na papierze” - Microsoft później wycofał usługę. Vindication! 🎯 Matryca decyzyjna z czterema kryteriami: koszty, łatwość zarządzania, elastyczność, strategia wyjścia. Azure Flexible Server wyglądał obiecująco, ale brak table spaces i replika tylko w tym samym regionie dyskwalifikują przy prawdziwej skali. Łukasz przypomina: „Parę lat temu byśmy powiedzieli: nie próbuj tego hostować na Kubernetesie.” Czasy się zmieniły. Zwycięzca? Cloud Native PG na AKS - narzut operacyjny większy, ale oszczędności kosztowe na tyle duże, że zostaje miejsce na kilka dodatkowych etatów. Łukasz: „Wraz ze wzrostem skali i potrzeb taniej zrobić to na Kubernetesie.” Ale ostrzega: „Hasło ‘zbudujemy kompetencje’ potrafi być mitem” - managersko ktoś wysyła na szkolenie i myśli, że ma już ekspertów. ⚠️ A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia
Szukaj w treści odcinka
Zaczył klient, korzystał już generalnie, miał wydarzony jakąś próbę z Cloud Native PG na AKS-ie.
Tak, jeżeli chodzi o narzut utrzymywania na Cloud ATV PG, on wbrew pozorom nie wyszedł tak bardzo dużo większy.
Inaczej, teraz trzeba sobie tylko jeden element powiedzieć, żeby inaczej, w porównaniu do tych scenariuszy te Cloud Native PG, inaczej, tak jest zajebiste, to trzeba bez dwóch zdań.
Przy tej skali jest i tak narzut operacyjny, który jest duży na przykład z upgradami.
Jest, chociaż nad tymi upgrade'ami też pracują, one też się zmieniają, bo faktycznie on umie robić te rolling update'y i tak dalej.
Cloud Native PG jako długofalowy to jest ten wybór słuszny.
Krótkofalowo, flexible server może, ale jak już klient ruszył z Client FPG, nie było to sensu, więc został na Client FPG, tylko tam jeszcze z sugestiami, jak to zrobić właśnie w kontekście disaster recovery, w kontekście HA i takie drobne zmiany, jeżeli chodzi właśnie o jak sobie poradzić z poaufem do czasu wyjścia wersji 18 i tak dalej i tak dalej.
Zauważ, że jak dyskutowaliśmy, sam ci powiedziałem, że trzeba rozborować Cloud Native PG mocno.
Zalando, no niestety, Cloud Native PG przebiło, tak.
Ostatnie odcinki
-
Stan frontendu i ekosystemu JS 2026 z Tomkiem D...
17.04.2026 06:00
-
Context switching, Brain Fry i praca z agentami
10.04.2026 06:00
-
Jak się ma Python w 2026? z Sebastianem Buczyn...
03.04.2026 06:00
-
Z życia Protopii - gdzie hostować postgresa?
27.03.2026 07:00
-
Ingress NGINX odchodzi - co teraz?
20.03.2026 07:00
-
Short #77: Szwajcaria vs Palantir, React Founda...
13.03.2026 07:00
-
Jak sobie radzić z możliwościami zespołów?
06.03.2026 07:00
-
Terraform to trup?
27.02.2026 07:00
-
Short #76: Human in the Loop, OpenAI Postgres n...
20.02.2026 07:00
-
PoC agentowe: Kill, Iterate, Scale
13.02.2026 07:00