Platforma
Wersje Postgresa i aktualizacje
Aktualizacje poprawkowe, przejście 15 → 17, hb1, okna serwisowe, raport zgodności, dry-run i wycofanie.
Każdy projekt działa na jednym obrazie Postgresa (Supabase). W Ustawienia → Infrastruktura → Wersja Postgresa widzisz bieżącą wersję, dostępne wersje docelowe (z linkiem do listy zmian), możesz sprawdzić zgodność, zaplanować aktualizację i śledzić jej postęp.
Rodzaje aktualizacji
| Typ | Przykład | Przerwa | Jak działa |
|---|---|---|---|
| Poprawkowa | 17.6.1.136 → 17.6.1.178 | kilkanaście–kilkadziesiąt sekund | wymiana obrazu kontenera bazy; dane zostają na miejscu |
| Wariant | standard → hb1 (pg_ivm, pg_search) | j.w. | j.w.; powrót hb1 → standard jest zablokowany, dopóki używasz pg_ivm/pg_search |
| Główna | 15 → 17 | zwykle 1–5 min (zależy od rozmiaru) | pg_upgrade w trybie kopii; stary katalog danych zostaje do Twojego potwierdzenia |
Nowy projekt możesz utworzyć na PostgreSQL 15 (postgres_version: "15" w API/MCP) i zaktualizować do 17 później.
Bezpieczeństwo aktualizacji
- Sprawdź zgodność — raport: dostępność rozszerzeń w nowej wersji, kolumny typów
reg*, tabele UNLOGGED, repliki odczytu, miejsce na dysku i szacowana przerwa. Nic nie zmienia. - Kopia zapasowa wykonywana automatycznie tuż przed zmianą, plus odcisk danych (liczby wierszy, role, rozszerzenia, uprawnienia schematów) porównywany po aktualizacji.
- Automatyczne wycofanie — jeśli start albo weryfikacja nie powiodą się, wracamy do poprzedniego obrazu (i katalogu danych w aktualizacji głównej), a właściciele dostają powiadomienie.
- Dry-run (aktualizacje główne) — pełna próba na kopii bazy: mierzy rzeczywisty czas przerwy i wykrywa problemy, nie dotykając działającego projektu.
- Wycofanie po aktualizacji głównej — do czasu potwierdzenia (domyślnie 14 dni) możesz wrócić do starej wersji; zapisy wykonane po aktualizacji zostaną utracone. Potwierdzenie usuwa stary katalog danych.
- Po aktualizacji głównej dotychczasowe punkty PITR są niedostępne (nowa kopia bazowa powstaje automatycznie); repliki odczytu trzeba usunąć przed aktualizacją i utworzyć ponownie.
Okno serwisowe i powiadomienia
Aktualizację możesz uruchomić od razu albo zaplanować (czas polski, od 10 minut do 30 dni naprzód). Właściciele i administratorzy dostają powiadomienie w panelu i e-mail przy zaplanowaniu, przypomnienia 24 h i 1 h przed oknem oraz wiadomość o starcie, sukcesie lub niepowodzeniu (także na skonfigurowanych kanałach: Slack, Discord, webhook).
API, MCP i CLI
GET /api/v1/projects/{ref}/postgres-version # wersja, cele, harmonogram, historia
POST /api/v1/projects/{ref}/postgres-version/check {"to": "17.6.1.178"}
POST /api/v1/projects/{ref}/postgres-version/upgrade {"to": "17.6.1.178", "scheduled_for": "2026-10-20T00:00:00Z", "dry_run": false}
GET /api/v1/projects/{ref}/postgres-version/upgrades/{id} # postęp + log
DELETE /api/v1/projects/{ref}/postgres-version/upgrades/{id} # anuluj termin
POST /api/v1/projects/{ref}/postgres-version/confirm
POST /api/v1/projects/{ref}/postgres-version/rollback {"acknowledge_data_loss": true}hostbase db upgrade # wersja i dostępne cele
hostbase db upgrade --check --to 17.6.1.178 # raport zgodności
hostbase db upgrade --to 17.6.1.178 --at 2026-10-20T02:00:00+02:00
hostbase db upgrade --to 17.6.1.178 --dry-run # próba na kopii (wersje główne)
hostbase db upgrade confirm | rollback | cancel <id> | log <id>MCP: get_postgres_version, check_postgres_upgrade, upgrade_postgres, cancel_postgres_upgrade, confirm_postgres_upgrade, rollback_postgres_upgrade.