Objectopslag vs database-blobs voor snelle, goedkope uploads

Het echte probleem met gebruikersuploads

Gebruikersuploads klinken simpel: accepteer een bestand, sla het op, toon het later. Dat werkt met een paar gebruikers en kleine bestanden. Vervolgens groeit het volume, worden bestanden groter, en verschijnen de problemen op plekken die niets met de uploadknop te maken hebben.

Downloads worden traag omdat je app-server of database het zware werk doet. Backups worden groot en traag, waardoor restores langer duren precies wanneer je ze nodig hebt. Opslag- en bandbreedtekosten (egress) kunnen pieken omdat bestanden inefficiënt worden geserveerd, gedupliceerd, of nooit worden opgeruimd.

Wat je meestal wilt is saai en betrouwbaar: snelle overdrachten onder load, heldere toegangsregels, eenvoudige operaties (backup, restore, cleanup) en kosten die voorspelbaar blijven als het gebruik groeit.

Om daar te komen, splits twee zaken die vaak door elkaar lopen:

Metadata is kleine informatie over een bestand: wie het bezit, hoe het heet, grootte, type, wanneer het is geüpload en waar het woont. Dit hoort in je database (zoals Postgres) omdat je het moet zoeken, filteren en joinen met gebruikers, projecten en permissies.

Bestandsbytes zijn de eigenlijke inhoud van het bestand (de foto, PDF, video). Bytes in database-blobs stoppen kan werken, maar het maakt databases zwaarder, backups groter en prestaties lastiger voorspelbaar. Bytes in objectopslag plaatsen houdt de database gefocust op waar die goed in is, terwijl systemen die voor dat werk gebouwd zijn bestanden snel en goedkoop serveren.

Objectopslag vs blobs in een database, in duidelijke taal

Als mensen zeggen "sla uploads in de database op" bedoelen ze meestal database-blobs: ofwel een BYTEA-kolom (ruwe bytes in een rij) of Postgres "large objects" (een feature die grote waarden apart opslaat). Beide kunnen werken, maar beide maken je database verantwoordelijk voor het serveren van bestandsbytes.

Objectopslag is een ander idee: het bestand leeft in een bucket als een object, aangesproken met een key (zoals uploads/2026/01/file.pdf). Het is gebouwd voor grote bestanden, goedkope opslag en streaming downloads. Het gaat ook veel gelijktijdige reads beter af, zonder je databaseconnecties op te eten.

Postgres blinkt uit in queries, constraints en transacties. Het is ideaal voor metadata zoals wie het bestand bezit, wat het is, wanneer het geüpload is en of het gedownload mag worden. Die metadata is klein, makkelijk te indexeren en eenvoudig consistent te houden.

Een praktische vuistregel:

• Gebruik Postgres voor bestandsmetadata, permissies en relaties.
• Gebruik objectopslag voor de bytes wanneer bestanden groter worden dan een paar MB, of wanneer downloads frequent zijn.
• Overweeg DB-blobs alleen voor piepkleine assets die transactioneel gekoppeld moeten zijn aan een record (zoals een klein icoon) en je zeker weet dat de database-groei beperkt blijft.

Een snelle sanity-check: als backups, replicas en migraties pijnlijk worden met bytes erbij, houd de bytes dan buiten Postgres.

Een eenvoudige architectuur die beheersbaar blijft

De opzet waar de meeste teams op uitkomen is rechttoe-rechtaan: bewaar bytes in objectopslag en het bestandsrecord (wie het bezit, wat het is, waar het woont) in Postgres. Je API coördineert en autoriseert, maar proxy't geen grote uploads en downloads.

Dat geeft je drie duidelijke verantwoordelijkheden:

• Postgres bevat één kleine rij per bestand: een stabiele file_id, owner, grootte, content type en de object-pointer.
• Objectopslag bevat de daadwerkelijke bytes, geoptimaliseerd voor grote bestanden en goedkope opslag.
• Je API maakt en autoriseert bestandsrecords en geeft kortlopende permissies voor opslag.

Die stabiele file_id wordt de primaire sleutel voor alles: comments die naar een bijlage verwijzen, facturen die naar een PDF wijzen, auditlogs en supporttools. Gebruikers kunnen een bestand hernoemen, je kunt het tussen buckets verplaatsen, en de file_id blijft hetzelfde.

Behandel opgeslagen objecten waar mogelijk als immutabel. Als een gebruiker een document vervangt, maak een nieuw object (en meestal een nieuwe rij of een nieuwe versie-rij) in plaats van bytes ter plaatse te overschrijven. Dat vereenvoudigt caching, voorkomt dat "oude link wijst naar nieuw bestand"-verrassingen en geeft een helder rollback-verhaal.

Bepaal privacy vroeg: standaard privé, publiek alleen bij uitzondering. Een goede regel is: de database is de bron van waarheid voor wie een bestand mag benaderen; objectopslag handhaaft de kortlopende permissie die je API uitgeeft.

Hoe je bestandsmetadata in Postgres modelleert

Met de cleane split bewaart Postgres feiten over het bestand en objectopslag bewaart de bytes. Dat houdt je database kleiner, backups sneller en queries eenvoudig.

Een praktisch uploads-table heeft maar een paar velden nodig om echte vragen te beantwoorden zoals "wie bezit dit?", "waar is het opgeslagen?" en "is het veilig om te downloaden?"

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

Een paar beslissingen die later pijn besparen:

• Gebruik bucket + object_key als de opslagpointer. Houd het immutabel nadat het geüpload is.
• Houd state bij. Als een gebruiker een upload start, insert een pending-rij. Schakel naar uploaded pas nadat je systeem bevestigt dat het object bestaat en de grootte (en idealiter checksum) klopt.
• Sla original_filename op alleen voor weergave. Vertrouw het niet voor type- of beveiligingsbeslissingen.

Als je vervangingen ondersteunt (zoals een gebruiker die een factuur opnieuw uploadt), voeg dan een aparte upload_versions-tabel toe met upload_id, version, object_key en created_at. Zo kun je geschiedenis bewaren, fouten terugdraaien en oude verwijzingen niet breken.

Uploadflow stap voor stap (zonder je API te blokkeren)

Houd uploads snel door je API coördinatie te laten doen, niet de bytes. Je database blijft responsief terwijl objectopslag de bandbreedtelast opvangt.

Begin met het aanmaken van een uploadrecord voordat er iets verstuurd wordt. Je API geeft een upload_id terug, waar het bestand zal wonen (een object_key) en een kortlopende uploadpermissie.

Een veelvoorkomende flow:

1. Client vraagt om te uploaden: je API maakt een rij met pending, plus verwachte grootte en bedoeld content type.
2. API retourneert een presigned URL: voor grote bestanden genereer je een presigned upload-URL. Voor kleine bestanden (zoals avatars) kun je nog steeds via je backend proxy'en als je simpelere clientcode wilt.
3. Client uploadt direct naar objectopslag: de browser of mobiele app stuurt bytes naar opslag, niet via je API.
4. Finaliseren: de client roept je API aan met upload_id en eventuele storage response-velden (zoals ETag). Je server verifieert grootte, checksum (als je die gebruikt) en content type, en markeert de rij als uploaded.
5. Veilig falen: als verificatie faalt, markeer failed en verwijder eventueel het object.

Retries en duplicaten zijn normaal. Maak de finalize-aanroep idempotent: als dezelfde upload_id twee keer gefinaliseerd wordt, retourneer dan succes zonder iets te veranderen.

Om duplicaten over retries en heruploads te verminderen, sla een checksum op en behandel "zelfde owner + dezelfde checksum + dezelfde grootte" als hetzelfde bestand.

Downloadflow stap voor stap (snel en cachevriendelijk)

Een goede downloadflow begint met één stabiele URL in je app, zelfs als de bytes ergens anders leven. Denk: /files/{file_id}. Je API gebruikt file_id om metadata in Postgres op te zoeken, controleert permissies en beslist vervolgens hoe het bestand geleverd wordt.

1. Client vraagt je stabiele URL met file_id op.
2. API verifieert dat de gebruiker er toegang toe heeft en dat het bestand uploaded is.
3. API retourneert ofwel een redirect naar objectopslag (meestal het beste), of een kortlopende presigned GET-URL voor privébestanden.
4. Client downloadt rechtstreeks van objectopslag, waardoor je API en app-servers uit het hot path blijven.

Redirects zijn simpel en snel voor publieke of semi-publieke bestanden. Voor privébestanden houden presigned GET-URL's opslag privé terwijl de browser toch direct kan downloaden.

Voor video en grote downloads, zorg dat je objectopslag (en eventuele proxylaag) range requests ondersteunt (Range-headers). Zo kan er worden gezocht en kunnen downloads hervat worden. Als je bytes via je API funnel't, breekt range-ondersteuning vaak of wordt het duur.

Caching is waar snelheid vandaan komt. Je stabiele /files/{file_id}-endpoint moet meestal niet cachebaar zijn (het is een auth-gate), terwijl de objectopslag-respons vaak wel op content kan worden gecachet. Als bestanden immutabel zijn (nieuwe upload = nieuwe key), kun je lange cachetijden zetten. Als je bestanden overschrijft, houd cachetijden kort of gebruik versioned keys.

Een CDN helpt bij veel globale gebruikers of grote bestanden. Als je doelgroep klein of regio-gecentreerd is, is objectopslag alleen vaak voldoende en goedkoper om mee te beginnen.

Kosten voorspelbaar houden over tijd

Verrassingsrekeningen komen meestal van downloads en churn, niet van de ruwe bytes op schijf.

Prijs de vier drivers die het verschil maken: hoeveel je opslaat, hoe vaak je leest en schrijft (requests), hoeveel data je provider verlaat (egress), en of je een CDN gebruikt om herhaalde origin-downloads te verminderen. Een klein bestand dat 10.000 keer gedownload wordt, kan meer kosten dan een groot bestand dat niemand aanraakt.

Controles die de uitgaven stabiel houden:

• Limiteer bestandsgrootte per upload en stel per-gebruiker quota in op basis van je plan.
• Rate-limit uploads en downloads om misbruik en accidenten te voorkomen.
• Gebruik lifecycle-regels zodat oude bestanden naar een goedkopere klasse verhuizen of verdwijnen wanneer ze niet meer nodig zijn.
• Deduplicate op checksum zodat retries of heruploads geen extra kopieën maken.
• Sla gebruikscounters in Postgres op zodat billing en alerts op feiten gebaseerd zijn, niet op schattingen.

Lifecycle-regels zijn vaak de makkelijkste winst. Bijvoorbeeld: houd originele foto’s "hot" voor 30 dagen en verplaats ze daarna naar een goedkopere opslagklasse; houd facturen 7 jaar en verwijder mislukte upload-onderdelen na 7 dagen. Zelfs basis retentiepolicies stoppen opslaggroei.

Deduplicatie kan simpel zijn: sla een content-hash (zoals SHA-256) op in je metadata-tabel en handhaaf uniekheid per owner. Als een gebruiker dezelfde PDF twee keer uploadt, kun je het bestaande object hergebruiken en alleen een nieuwe metadata-rij aanmaken.

Tot slot: track gebruik waar je al user accounting doet: Postgres. Sla bytes_uploaded, bytes_downloaded, object_count en last_activity_at op per gebruiker of workspace. Zo kun je limieten tonen in de UI en alerts triggeren voordat de rekening te hoog wordt.

Basisveiligheid en compliance voor uploads

Beveiliging voor uploads komt neer op twee dingen: wie kan een bestand benaderen, en wat je later kunt aantonen als er iets misgaat.

Toegangscontrole die bij de praktijk past

Begin met een duidelijk toegangmodel en codificeer het in Postgres-metadata, niet in losse regels verspreid over services.

Een simpel model dat de meeste apps dekt:

• Owner-only: alleen de uploader (en admins) kunnen erbij.
• Shared: toegankelijk voor specifieke gebruikers of een team/workspace.
• Public: toegankelijk zonder login (gebruik spaarzaam en track het alsnog).

Voor privébestanden, vermijd het blootstellen van ruwe object-keys. Geef kortlopende, scope-gerelateerde presigned upload- en download-URL's uit en roteer ze vaak.

Compliance-checks die je later tijd besparen

Verifieer encryptie in transit en at rest. In transit betekent end-to-end HTTPS, inclusief uploads direct naar opslag. At rest betekent server-side encryptie bij je storageprovider en dat backups en replicas ook versleuteld zijn.

Voeg checkpoints toe voor veiligheid en datakwaliteit: valideer content-type en grootte voordat je een upload-URL uitgeeft, en valideer opnieuw na upload (gebaseerd op daadwerkelijk opgeslagen bytes, niet alleen op de bestandsnaam). Als je risicoprofiel het vereist, voer dan asynchrone malware-scans uit en quarantaineer het bestand totdat het schoon is.

Sla auditvelden op zodat je incidenten kunt onderzoeken en aan basis-compliance kunt voldoen: uploaded_by, ip, user_agent en last_accessed_at zijn een praktisch minimum.

Als je dataresidency-eisen hebt, kies de opslagregio bewust en houd die consistent met waar je compute draait.

Veelvoorkomende fouten die vertragingen en incidenten veroorzaken

De meeste uploadproblemen gaan niet over ruwe snelheid. Ze komen voort uit ontwerpkeuzes die vroeg handig lijken en pijnlijk worden als je echte traffic, echte data en echte supporttickets hebt.

• Bestandsbytes in Postgres opslaan: Het werkt voor kleine apps, maar backups zwellen aan, restores duren lang en routineonderhoud wordt riskant. Een enkele grote tabel kan vacuum, replicatie en zelfs simpele queries vertragen.
• De gebruikersgegeven bestandsnaam als object_key gebruiken: Botsingen komen voor (twee gebruikers uploaden "invoice.pdf"), en vreemde tekens creëren randgevallen. Houd bestandsnamen voor weergave, maar genereer een unieke key (zoals een UUID) voor opslag.
• Validatie overslaan bij finaliseren: Zelfs als je aan de client valideert, heb je server-side checks nodig voor grootte, content-type en eigendom wanneer je een upload als voltooid markeert.
• Per ongeluk objecten publiek maken en nooit toegang roteren: Een "tijdelijke" publieke bucket-policy of langlevende URL's worden vaak permanent. Geef voorkeur aan kortlopende downloadlinks en zorg voor een manier om snel toegang te intrekken.
• Slechts één kant verwijderen (metadata of bytes): Een Postgres-rij verwijderen maar het object laten staan veroorzaakt stille kostenlekken. Het object verwijderen maar metadata bewaren veroorzaakt kapotte downloads en supportload.

Een concreet voorbeeld: als een gebruiker een profielfoto drie keer vervangt, kun je opdraaien voor drie oude objecten voor altijd tenzij je cleanup plant. Een veilig patroon is soft delete in Postgres, gevolgd door een achtergrondjob die het object verwijdert en het resultaat registreert.

Snelle pre-launch checklist

De meeste problemen komen naar boven wanneer het eerste grote bestand binnenkomt, een gebruiker ververst midden in een upload, of iemand een account verwijdert en de bytes blijven liggen.

Zorg dat je Postgres-tabel de bestandsgrootte, checksum (zodat je integriteit kunt verifiëren) en een duidelijke state-path (bijv. pending, uploaded, failed, deleted) vastlegt.

Een checklijst voor de laatste kilometer:

• Bevestig dat retries veilig zijn: herhaalde pogingen mogen geen extra objecten of "uploaded"-rijen zonder bytes creëren.
• Maak uploads hervatbaar of ten minste herstartbaar zonder supporttickets (timeouts en mobiele netwerken gebeuren).
• Verifieer dat downloads range-requests ondersteunen zodat grote bestanden snel kunnen starten en hervat kunnen worden na een onderbreking.
• Definieer verwijderen end-to-end: tombstone metadata, verwijder objectbytes en handel vertraagde cleanup af als een job faalt.
• Voeg basismonitoring toe: upload/download foutpercentages, opslaggroei en plotselinge egress-pieken.

Een concrete test: upload een 2 GB bestand, ververs de pagina bij 30% en hervat. Download het vervolgens op een langzame verbinding en zoek naar het midden. Als een van beide flows haperend is, los het dan nu op, niet na launch.

Voorbeeldscenario: foto’s en facturen in één app

Een simpele SaaS-app heeft vaak twee heel verschillende uploadtypes: profielfoto’s (frequent, klein, veilig te cacheren) en PDF-facturen (gevoelig, privé). Dit is waar de split tussen metadata in Postgres en bytes in objectopslag zich terugbetaalt.

Zo kan metadata eruitzien in één files-tabel, met een paar velden die het gedrag bepalen:

Als een gebruiker een foto vervangt, behandel dat als een nieuw bestand, geen overschrijving. Maak een nieuwe rij en nieuwe object_key, en update het gebruikersprofiel om naar het nieuwe file ID te wijzen. Markeer de oude rij als replaced_by=\u003cnew_id\u003e (of deleted_at) en verwijder het oude object later met een achtergrondjob. Dit behoudt geschiedenis, maakt rollbacks eenvoudiger en voorkomt race-voorwaarden.

Support en debuggen worden makkelijker omdat de metadata een verhaal vertelt. Als iemand zegt "mijn upload faalde", kan support status, een leesbare last_error, een storage_request_id of etag (om storage logs te traceren), tijdstempels (stond het vast?), en owner_id en kind controleren (is de access policy juist?).

Volgende stappen om te implementeren zonder te overbouwen

Begin klein en maak het gelukkige pad saai: bestanden uploaden, metadata opslaan, downloads zijn snel en er gaat niets verloren.

Een goed eerste mijlpaal is een minimaal Postgres-schema voor bestandsmetadata plus één uploadflow en één downloadflow die je op een whiteboard kunt uitleggen. Zodra dat end-to-end werkt, voeg je versies, quota en lifecycle-regels toe.

Kies één duidelijk opslagbeleid per bestandstype en leg het vast. Bijvoorbeeld: profielfoto’s mogen cachebaar zijn, terwijl facturen privé moeten blijven en alleen via kortlopende download-URL's toegankelijk zijn. Policies mixen binnen één bucket-prefix zonder plan is hoe onbedoelde blootstelling gebeurt.

Voeg instrumentatie vroeg toe. De cijfers die je vanaf dag één wilt hebben zijn finalize-failure-rate, orphan-rate (objecten zonder bijhorende DB-rij en omgekeerd), egress-volume per bestandstype, P95 download-latency en gemiddelde objectgrootte.

Als je snel wilt prototypen volgens dit patroon, is Koder.ai (koder.ai) gebouwd rond het genereren van complete apps vanuit chat en sluit het aan op de gebruikelijke stack hier (React, Go, Postgres). Het kan handig zijn om schema's, endpoints en achtergrondcleanup-jobs sneller te itereren zonder steeds dezelfde scaffolding te herhalen.

Daarna voeg je alleen toe wat je in één zin kunt uitleggen: "we bewaren oude versies 30 dagen" of "elke workspace krijgt 10 GB." Houd het simpel totdat echt gebruik je dwingt iets anders te doen.