Przechowywanie obiektowe vs bloby w bazie danych dla szybkich, tanich przesyłów

Prawdziwy problem z uploadami użytkowników

Uploady użytkowników brzmią prosto: przyjmij plik, zapisz go, pokaż później. To działa przy kilku użytkownikach i małych plikach. Potem rośnie wolumen, pliki stają się większe i ból pojawia się w miejscach, które nie mają nic wspólnego z przyciskiem "wyślij".

Pobieranie zwalnia, bo serwer aplikacji lub baza wykonuje ciężką pracę. Backupy stają się ogromne i wolne, więc przywrócenie trwa dłużej wtedy, gdy najbardziej tego potrzebujesz. Rachunki za przechowywanie i transfer (egress) mogą skoczyć, bo pliki są serwowane nieefektywnie, duplikowane lub nigdy nie sprzątnięte.

Zwykle chcesz czegoś nudnego i niezawodnego: szybkich transferów pod obciążeniem, jasnych zasad dostępu, prostych operacji (backup, restore, sprzątanie) i kosztów, które pozostają przewidywalne wraz ze wzrostem użycia.

Aby to osiągnąć, rozdziel dwie rzeczy, które często się mieszają:

Metadane to małe informacje o pliku: kto jest właścicielem, jak się nazywa, rozmiar, typ, kiedy został przesłany i gdzie się znajduje. To należy trzymać w bazie (np. Postgres), bo potrzebujesz móc tego szukać, filtrować i łączyć z użytkownikami, projektami i uprawnieniami.

Bajty pliku to rzeczywista zawartość (zdjęcie, PDF, wideo). Przechowywanie bajtów w blobach bazy może działać, ale powoduje, że baza staje się cięższa, backupy większe, a wydajność trudniejsza do przewidzenia. Umieszczenie bajtów w storage obiektowym pozwala bazie robić to, co robi najlepiej, a pliki są serwowane szybko i tanio przez systemy do tego stworzone.

Storage obiektowy vs bloby w bazie, prosto

Gdy ludzie mówią "przechowuj uploady w bazie", zwykle mają na myśli bloby: albo kolumnę BYTEA (surowe bajty w wierszu), albo Postgresowe "large objects" (funkcja przechowująca duże wartości osobno). Oba rozwiązania działają, ale oba obciążają bazę odpowiedzialnością za serwowanie bajtów.

Storage obiektowy to inny pomysł: plik żyje w bucketcie jako obiekt, adresowany kluczem (np. uploads/2026/01/file.pdf). Jest stworzony do dużych plików, taniego przechowywania i strumieniowego pobierania. Dobrze radzi sobie z wieloma równoczesnymi odczytami, bez wiązania połączeń bazy.

Postgres błyszczy w zapytaniach, ograniczeniach i transakcjach. Świetnie nadaje się do metadanych: kto jest właścicielem pliku, co to jest, kiedy to przesłano i czy można to pobrać. Te metadane są małe, łatwe do indeksowania i proste do utrzymania spójności.

Praktyczna zasada:

• Używaj Postgresa do metadanych plików, uprawnień i relacji.
• Używaj storage obiektowego do bajtów, gdy pliki będą większe niż kilka MB lub gdy pobrania są częste.
• Rozważ bloby w bazie tylko dla maleńkich zasobów, które muszą być transakcyjnie powiązane z rekordem (np. mała ikona) i gdy wzrost bazy pozostanie umiarkowany.

Szybki test zdrowego rozsądku: jeśli backupy, repliki i migracje stałyby się problemem z powodu bajtów w bazie, trzymaj bajty poza Postgresem.

Prosta architektura, która pozostaje znośna

Ustawienie, do którego większość zespołów dochodzi, jest proste: bajty w storage obiektowym, rekord pliku (kto, co, gdzie) w Postgresie. Twoje API koordynuje i autoryzuje, ale nie proxy'uje dużych uploadów i downloadów.

To daje trzy jasne odpowiedzialności:

• Postgres trzyma jeden mały wiersz na plik: stabilne file_id, właściciel, rozmiar, content type i wskaźnik do obiektu.
• Storage obiektowy trzyma rzeczywiste bajty, zoptymalizowane pod kątem dużych plików i taniego przechowywania.
• Twoje API tworzy i autoryzuje rekordy plików oraz wydaje krótkotrwałe uprawnienia do storage.

To stabilne file_id staje się kluczem głównym dla wszystkiego: komentarzy odnoszących się do załącznika, faktur wskazujących PDF, logów audytu i narzędzi wsparcia. Użytkownik może zmienić nazwę pliku, możesz przenieść go między bucketami — file_id pozostaje ten sam.

Gdy to możliwe, traktuj obiekty jako niemutowalne. Jeśli użytkownik zastępuje dokument, utwórz nowy obiekt (i zwykle nowy wiersz lub wersję) zamiast nadpisywać bajty w miejscu. Upraszcza to cache'owanie, unika niespodzianek typu "stary link zwraca nowy plik" i daje prostą ścieżkę rollbacku.

Zdecyduj o prywatności wcześnie: domyślnie prywatne, publiczne tylko wyjątkowo. Dobra zasada: baza jest źródłem prawdy, kto może dostać plik; storage egzekwuje krótkotrwałe uprawnienia wydane przez API.

Jak modelować metadane pliku w Postgresie

Przy czystym rozdziale Postgres przechowuje fakty o pliku, a storage bajty. To trzyma bazę mniejszą, backupy szybsze i zapytania proste.

Praktyczna tabela uploads potrzebuje kilku pól, by odpowiedzieć na pytania typu "kto jest właścicielem?", "gdzie się to znajduje?" i "czy da się to pobrać?"

CREATE TABLE uploads (
  id               uuid PRIMARY KEY,
  owner_id         uuid NOT NULL,
  bucket           text NOT NULL,
  object_key       text NOT NULL,
  size_bytes       bigint NOT NULL,
  content_type     text,
  original_filename text,
  checksum         text,
  state            text NOT NULL CHECK (state IN ('pending','uploaded','failed','deleted')),
  created_at       timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX uploads_owner_created_idx ON uploads (owner_id, created_at DESC);
CREATE INDEX uploads_checksum_idx ON uploads (checksum);

Kilka decyzji, które oszczędzają kłopotów później:

• Używaj bucket + object_key jako wskaźnika do przechowywania. Trzymaj to niemutowalne po przesłaniu.
• Śledź state. Gdy użytkownik zaczyna upload, wstaw wiersz pending. Przełącz na uploaded dopiero po potwierdzeniu, że obiekt istnieje i rozmiar (a idealnie suma kontrolna) się zgadza.
• Przechowuj original_filename tylko do wyświetlania. Nie ufaj mu w kwestiach typu czy bezpieczeństwa.

Jeśli obsługujesz zastępowanie (np. użytkownik ponownie przesyła fakturę), dodaj osobną tabelę upload_versions z upload_id, version, object_key i created_at. Dzięki temu zachowasz historię, cofniesz zmiany i unikniesz psucia starych odwołań.

Przepływ uploadu krok po kroku (bez blokowania API)

Utrzymaj uploady szybkie, sprawiając, że API koordynuje, a nie przesyła bajtów. Baza pozostaje responsywna, a storage bierze na siebie ruch sieciowy.

Zacznij od stworzenia rekordu uploadu zanim cokolwiek zostanie wysłane. API zwraca upload_id, gdzie plik będzie przechowywany (object_key) i krótkotrwałe uprawnienie do uploadu.

Typowy przepływ:

1. Klient prosi o upload: API tworzy wiersz z pending, wraz z oczekiwanym rozmiarem i zamierzonym content type.
2. API zwraca presigned URL: dla dużych plików wygeneruj presigned upload URL. Dla malutkich plików (np. avatary) możesz wciąż proxy'ować przez backend, jeśli chcesz prostszy kod klienta.
3. Klient uploaduje bezpośrednio do storage: przeglądarka lub aplikacja mobilna wysyła bajty do storage, nie przez API.
4. Finalizacja: klient wywołuje API z upload_id i polami odpowiedzi storage (np. ETag). Serwer weryfikuje rozmiar, sumę kontrolną (jeśli używasz) i content type, potem oznacza wiersz jako uploaded.
5. Bezpieczne porażki: jeśli weryfikacja zawiedzie, oznacz failed i opcjonalnie usuń obiekt.

Retry i duplikaty są normalne. Spraw, by wywołanie finalizacji było idempotentne: jeśli to samo upload_id zostanie sfinalizowane dwukrotnie, zwróć sukces bez zmiany stanu.

Aby zmniejszyć duplikaty przy retryach i ponownych uploadach, przechowuj sumę kontrolną i traktuj "ten sam właściciel + ta sama suma + ten sam rozmiar" jako ten sam plik.

Przepływ pobierania krok po kroku (szybko i przyjazny cache'owi)

Dobry przepływ pobierania zaczyna się od jednego stabilnego URL w aplikacji, nawet jeśli bajty są gdzie indziej. Pomyśl: /files/{file_id}. API używa file_id, żeby znaleźć metadane w Postgresie, sprawdza uprawnienia, a potem decyduje, jak dostarczyć plik.

1. Klient żąda stabilnego URL z file_id.
2. API weryfikuje, że użytkownik ma dostęp i że plik ma stan uploaded.
3. API zwraca przekierowanie do storage (często najlepsze) lub krótkotrwały presigned GET URL dla plików prywatnych.
4. Klient pobiera bezpośrednio ze storage, trzymając API i serwery aplikacyjne poza gorącą ścieżką.

Przekierowania są proste i szybkie dla publicznych lub półpublicznych plików. Dla prywatnych plików presigned GET URL zachowują storage prywatnym, a jednocześnie pozwalają przeglądarce pobrać plik bez udziału API.

Dla wideo i dużych pobrań upewnij się, że storage (i każda warstwa proxy) obsługuje zapytania zakresowe (Range headers). To umożliwia przewijanie i wznawianie. Jeśli funnelujesz bajty przez API, obsługa zakresów często przestaje działać lub staje się kosztowna.

Cache to źródło prędkości. Twój stabilny endpoint /files/{file_id} zwykle nie powinien być cache'owalny (to bramka autoryzacyjna), podczas gdy odpowiedź storage często można cache'ować na podstawie zawartości. Jeśli pliki są niemutowalne (nowy upload = nowy klucz), ustaw długie TTL. Jeśli nadpisujesz pliki, trzymaj krótkie czasy cache lub używaj wersjonowanych kluczy.

CDN pomaga, gdy masz dużo globalnych użytkowników lub duże pliki. Jeśli twoja publiczność jest mała lub głównie w jednym regionie, sam storage często wystarczy i jest tańszy na start.

Utrzymanie przewidywalnych kosztów w czasie

Zaskakujące rachunki zwykle wynikają z pobrań i churnu, nie z surowych bajtów na dysku.

Oszacuj cztery czynniki, które poruszają dźwignię kosztów: ile przechowujesz, jak często czytasz i zapisujesz (requesty), ile danych wychodzi od providera (egress) i czy używasz CDN, by zmniejszyć powtarzające się pobrania. Mały plik pobrany 10 000 razy może kosztować więcej niż duży plik, którego nikt nie dotyka.

Kontrole, które utrzymają wydatki w ryzach:

• Limituj rozmiar pliku na upload i ustal kwoty per-użytkownik zgodnie z planem.
• Ograniczaj prędkość uploadów i pobrań, by zapobiec nadużyciom i pętlom.
• Użyj reguł lifecycle, by stare pliki przenieść do tańszej klasy lub usunąć, gdy nie są już potrzebne.
• Deduplikuj po sumie kontrolnej, by retry i re-uploady nie tworzyły dodatkowych kopii.
• Przechowuj liczniki użycia w Postgresie, żeby rozliczenia i alerty były oparte na faktach.

Reguły lifecycle to często najprostszy zysk. Na przykład: trzymaj oryginalne zdjęcia "hot" przez 30 dni, potem przenieś do tańszej klasy; faktury trzymaj 7 lat; części nieudanych uploadów usuwaj po 7 dniach. Podstawowe polityki retencji powstrzymują przyrost storage.

Deduplikacja może być prosta: zapisz hash treści (np. SHA-256) w tabeli metadanych i wymuś unikalność per właściciel. Gdy użytkownik ponownie wrzuca ten sam PDF, możesz użyć istniejącego obiektu i stworzyć nowy wiersz metadanych.

Na koniec, śledź użycie tam, gdzie już robisz rozliczenia: w Postgresie. Przechowuj bytes_uploaded, bytes_downloaded, object_count i last_activity_at per użytkownik lub workspace. Dzięki temu łatwo pokazywać limity w UI i wyzwalać alerty zanim przyjdzie rachunek.

Bezpieczeństwo i zgodność dla uploadów

Bezpieczeństwo uploadów sprowadza się do dwóch rzeczy: kto może dostać plik i co potrafisz udowodnić później, jeśli coś pójdzie nie tak.

Kontrola dostępu dopasowana do potrzeb

Zacznij od jasnego modelu dostępu i zakoduj go w metadanych Postgresa, nie w jednorazowych regułach rozsianych po serwisach.

Prosty model, który wystarcza większości aplikacji:

• Tylko właściciel: tylko uploader (i admini) mogą uzyskać dostęp.
• Udostępnione: dostęp dla konkretnych użytkowników lub zespołu/workspace.
• Publiczne: dostęp bez logowania (używaj oszczędnie i nadal śledź).

Dla prywatnych plików unikaj ujawniania surowych kluczy obiektów. Wydawaj krótkotrwałe, ograniczone zakresem presigned URL dla uploadu i pobrania i rotuj je często.

Checki zgodności, które się opłacają później

Weryfikuj szyfrowanie w tranzycie i w spoczynku. W tranzycie oznacza HTTPS end-to-end, także przy uploadach bezpośrednio do storage. W spoczynku oznacza szyfrowanie po stronie providera storage i szyfrowanie backupów i replik.

Dodaj punkty kontrolne dla bezpieczeństwa i jakości danych: waliduj content type i rozmiar przed wydaniem URL do uploadu, potem waliduj znów po uploadzie (na podstawie rzeczywiście zapisanych bajtów, nie tylko nazwy pliku). Jeśli masz wyższe ryzyko, uruchamiaj asynchroniczne skanowanie antywirusowe i kwarantannuj plik do czasu czystego wyniku.

Przechowuj pola audytu, żeby móc badać incydenty i spełniać podstawowe wymagania zgodności: uploaded_by, ip, user_agent i last_accessed_at to praktyczne minimum.

Jeśli masz wymagania co do lokalizacji danych, wybierz region storage świadomie i trzymaj go spójnym z miejscem uruchamiania compute.

Częste błędy powodujące spowolnienia i incydenty

Większość problemów z uploadami nie dotyczy surowej szybkości. Wynikają z decyzji projektowych, które wydają się wygodne na początku, a potem bolesne przy realnym ruchu, danych i zgłoszeniach do supportu.

• Przechowywanie bajtów w Postgresie: Działa dla małych aplikacji, potem backupy pęcznieją, przywracanie trwa wieczność, a rutynowe utrzymanie staje się ryzykowne. Jedna duża tabela może spowolnić vacuum, replikację i nawet proste zapytania.
• Używanie nazwy pliku podanej przez użytkownika jako object_key: Zdarzają się kolizje (dwóch użytkowników wrzuca "invoice.pdf"), a dziwne znaki tworzą przypadki brzegowe. Trzymaj nazwę tylko do wyświetlania, generuj unikalny klucz (np. UUID) dla storage.
• Pominięcie walidacji przy finalizacji: Nawet jeśli walidujesz na kliencie, potrzebujesz walidacji po stronie serwera (rozmiar, content type, właściciel) zanim oznaczysz upload jako kompletny.
• Przypadkowe publiczne udostępnienie obiektów i brak rotacji dostępu: "Tymczasowa" polityka publiczna lub długożyjące URL-e często stają się trwałe. Preferuj krótkotrwałe linki i miej sposób szybkiego cofania dostępu.
• Usuwanie tylko jednej strony (metadanych lub bajtów): Usunięcie wiersza w Postgresie pozostawiające obiekt to cichy przeciek kosztów. Usunięcie obiektu, ale zachowanie metadanych powoduje złamane pobrania i zgłoszenia do supportu.

Konkretny przykład: jeśli użytkownik trzykrotnie zmienia zdjęcie profilowe, możesz płacić za trzy stare obiekty na zawsze, jeśli nie zaplanujesz sprzątania. Bezpieczny wzorzec to miękkie usunięcie w Postgresie, a potem zadanie w tle, które usuwa obiekt i zapisuje wynik.

Szybka lista kontrolna przed launchem

Większość problemów ujawnia się, gdy przychodzi pierwszy duży plik, użytkownik odświeża stronę w trakcie uploadu lub ktoś usuwa konto, a bajty zostają.

Upewnij się, że tabela Postgresa zapisuje rozmiar pliku, sumę kontrolną (by móc weryfikować integralność) i jasną ścieżkę stanów (np. pending, uploaded, failed, deleted).

Ostatnia lista kontroli:

• Upewnij się, że retry są bezpieczne: powtarzane próby nie powinny tworzyć dodatkowych obiektów ani wierszy "uploaded" bez bajtów.
• Zrób uploady wznawialnymi lub przynajmniej restartowalnymi bez konieczności wsparcia (timeouty i sieci mobilne się zdarzają).
• Zweryfikuj, że pobieranie obsługuje zapytania zakresowe, by duże pliki mogły szybko się rozpocząć i wznowić po przerwie.
• Zdefiniuj kasowanie end-to-end: oznacz metadane jako tombstone, usuń bajty obiektu i obsłuż opóźnione sprzątanie, jeśli zadanie się nie powiedzie.
• Dodaj podstawowy monitoring: współczynnik błędów upload/download, wzrost storage, nagłe skoki egressu.

Jeden konkretny test: wyślij plik 2 GB, odśwież stronę na 30%, potem wznow upload. Potem pobierz na wolnym łączu i przeskocz do środka. Jeśli któraś z tych ścieżek jest niestabilna, napraw to teraz, nie po starcie.

Przykładowy scenariusz: zdjęcia i faktury w jednej aplikacji

Prosta aplikacja SaaS często ma dwa różne typy uploadów: zdjęcia profilowe (częste, małe, bezpieczne do cache'owania) oraz PDF-y faktur (wrażliwe, prywatne). To tu rozdzielenie metadanych w Postgresie i bajtów w storage daje największe korzyści.

Tak mogą wyglądać metadane w jednej tabeli files, z kilkoma polami wpływającymi na zachowanie:

Gdy użytkownik zamienia zdjęcie, traktuj to jako nowy plik, a nie overwrite. Stwórz nowy wiersz i nowy object_key, potem zaktualizuj profil użytkownika, żeby wskazywał na nowe file_id. Oznacz stary wiersz jako replaced_by=<new_id> (lub ustaw deleted_at) i usuń stary obiekt później w zadaniu w tle. To zachowuje historię, ułatwia rollback i unika wyścigów.

Wsparcie i debugowanie stają się prostsze, bo metadane opowiadają historię. Gdy ktoś mówi "mój upload się nie powiódł", support może sprawdzić status, czytelne last_error, storage_request_id lub etag (do śledzenia logów storage), znaczniki czasu (czy zacięło się?) oraz owner_id i kind (czy polityka dostępu jest poprawna?).

Kolejne kroki — zacznij skromnie

Zacznij prosto i spraw, by happy path był nudny: pliki się uploadują, metadane zapisują, pobierania są szybkie i nic nie ginie.

Dobry pierwszy kamień milowy to minimalna tabela metadanych w Postgresie plus pojedynczy przepływ uploadu i pojedynczy przepływ pobierania, które potrafisz opisać na tablicy. Gdy to zadziała end-to-end, dodaj wersje, kwoty i reguły lifecycle.

Wybierz jedną jasną politykę storage per typ pliku i zapisz ją. Na przykład: avatary są cache'owalne, faktury prywatne i dostępne tylko przez krótkotrwałe URL. Mieszanie polityk w jednym prefixie bez planu to sposób na przypadkowe wycieki.

Dodaj metryki wcześniej. Liczby, które chcesz od dnia 1: współczynnik błędów finalizacji uploadu, współczynnik sierot (obiekty bez odpowiadającego wiersza DB i odwrotnie), wolumen egressu wg typu pliku, P95 latency pobierania i średni rozmiar obiektu.

Jeśli chcesz szybciej prototypować ten wzorzec, Koder.ai (koder.ai) jest zbudowany wokół generowania pełnych aplikacji z czatu i pasuje do wspólnego stacku tu opisanego (React, Go, Postgres). Może to być wygodny sposób iteracji nad schematem, endpointami i zadaniami w tle bez przepisywania szablonów.

Po tym dodawaj tylko to, co potrafisz wyjaśnić jednym zdaniem: "trzymamy stare wersje 30 dni" albo "każdy workspace ma 10 GB". Trzymaj prostotę, aż rzeczywiste użycie nie zmusi cię do zmian.