Objektlagring kontra databasblobs för snabba, billiga uppladdningar

Problemet med användaruppladdningar\n\nAnvändaruppladdningar låter enkla: ta emot en fil, spara den, visa den senare. Det funkar med några få användare och små filer. När volymen växer och filer blir större uppstår problem på platser som inte har något med uppladdningsknappen att göra.\n\nNedladdningar blir långsamma eftersom din appserver eller databas gör det tunga jobbet. Backuper blir stora och långsamma, så återställningar tar längre tid precis när du behöver dem. Lagringskostnader och bandbredd (utgående trafik) kan skjuta i höjden eftersom filer serveras ineffektivt, dupliceras eller aldrig tas bort.\n\nDet du oftast vill ha är tråkigt men pålitligt: snabba överföringar under belastning, tydliga åtkomstregler, enkla operationer (backup, restore, cleanup) och kostnader som förblir förutsägbara när användningen växer.\n\nFör att nå dit, separera två saker som ofta blandas ihop:\n\nMetadata är liten information om en fil: vem som äger den, vad den heter, storlek, typ, när den laddades upp och var den ligger. Detta hör hemma i din databas (som Postgres) eftersom du behöver query:a, filtrera och join:a mot användare, projekt och behörigheter.\n\nFilbyten är själva innehållet i filen (fotot, PDF:en, videon). Att lagra byten i databasblobs kan fungera, men det gör databasen tyngre, backuper större och prestandan svårare att förutsäga. Att lägga byten i objektlagring håller databasen fokuserad på det den gör bäst, samtidigt som filer serveras snabbt och billigt av system byggda för uppgiften.\n\n## Objektlagring vs blobs i en databas, enkelt förklarat\n\nNär folk säger "lagra uppladdningar i databasen" menar de oftast databasblobs: antingen en BYTEA-kolumn (råa bytes i en rad) eller Postgres "large objects" (en funktion som lagrar stora värden separat). Båda kan fungera, men båda gör din databas ansvarig för att servera filbyten.\n\nObjektlagring är en annan idé: filen ligger i en bucket som ett objekt, adresserat med en nyckel (som uploads/2026/01/file.pdf). Den är byggd för stora filer, billig lagring och strömmade nedladdningar. Den hanterar också många samtidiga läsningar väl, utan att binda upp dina databasanslutningar.\n\nPostgres glänser i frågor, constraints och transaktioner. Det är utmärkt för metadata som vem som äger filen, vad den är, när den laddades upp och om den kan laddas ned. Den metadata är liten, lätt att indexera och enkel att hålla konsekvent.\n\nEn praktisk tumregel:\n\n- Använd Postgres för filmetadata, behörigheter och relationer.\n- Använd objektlagring för byten när filer kan växa till mer än några MB, eller när nedladdningar är frekventa.\n- Överväg DB-blobs endast för pyttesmå tillgångar som måste vara transactionellt kopplade till en post (som en liten ikon) och du är säker på att databasens tillväxt förblir måttlig.\n\nEn snabb sundhetskontroll: om backuper, repliker och migrationer skulle bli besvärliga med filbyten inkluderade, håll bytena utanför Postgres.\n\n## En enkel arkitektur som är hanterbar\n\nUpplägget som de flesta team landar i är enkelt: lagra byten i objektlagring och lagra filposten (vem som äger den, vad den är, var den ligger) i Postgres. Din API koordinerar och auktoriserar, men proxy:ar inte stora uppladdningar och nedladdningar.\n\nDet ger dig tre tydliga ansvar:\n\n- Postgres håller en liten rad per fil: ett stabilt file_id, ägare, storlek, content type och pekare till objektet.\n- Objektlagring håller de faktiska bytena, optimerat för stora filer och billig lagring.\n- Din API skapar och auktoriserar filposter och delar ut kortlivade behörigheter till lagringen.\n\nDet stabila file_id blir primärnyckeln för allt: kommentarer som refererar en bilaga, fakturor som pekar på en PDF, audit logs och supportverktyg. Användare kan byta namn på en fil, du kan flytta den mellan buckets, och file_id förblir densamma.\n\nNär det är möjligt, behandla lagrade objekt som immutabla. Om en användare ersätter ett dokument, skapa ett nytt objekt (och vanligtvis en ny rad eller en ny versionsrad) istället för att skriva över byten på plats. Det förenklar caching, undviker "gammal länk visar ny fil"-överraskningar och ger en tydlig rollback-berättelse.\n\nBestäm sekretess tidigt: privat som standard, publik bara undantagsvis. En bra regel är: databasen är sanningskällan för vem som kan komma åt en fil; objektlagringen genomdriver de kortlivade behörigheter din API utfärdar.\n\n## Hur modellera filmetadata i Postgres\n\nMed den rena uppdelningen lagrar Postgres fakta om filen, och objektlagring lagrar bytena. Det håller din databas mindre, backuper snabbare och queries enkla.\n\nEn praktisk uploads-tabell behöver bara några fält för att svara på verkliga frågor som "vem äger detta?", "var lagras det?" och "är det säkert att ladda ner?"\n\n```sql

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);