Object Storage

Object storage is a data storage architecture that manages data as discrete, self-contained "objects" — each with the file's raw bytes, a unique identifier/key, and a flexible set of metadata — accessed over an HTTP API rather than through a traditional file system's directory/path hierarchy. It is the standard way modern applications store unstructured data: images, videos, PDFs, model checkpoint files, log archives, and (increasingly) the raw exports of embeddings or datasets used in AI pipelines. Why it matters for AI/SaaS builders: object storage is the quiet backbone under nearly every AI product feature involving user-uploaded files — profile pictures, documents fed into RAG pipelines, generated images and audio, exported reports. It's built for a completely different access pattern than a database: massive scale (effectively unlimited capacity), very high durability (S3, for example, is engineered for 99.999999999% — "eleven nines" — durability by storing multiple copies across facilities), and low cost per gigabyte, in exchange for higher latency per individual request and no support for partial-file updates the way a database row can be updated in place — you replace the whole object. How it works: objects live in flat namespaces called "buckets," each object addressed by a unique key (often mimicking a folder path like `users/442/uploads/contract.pdf` even though there's no real directory structure underneath). Access typically happens via signed URLs — the application server generates a time-limited, cryptographically signed URL granting temporary read or write access to a specific object, so a browser can upload directly to object storage without the file ever passing through the application's own servers (saving bandwidth and avoiding request-size limits). Object storage tiers (S3 Standard, Infrequent Access, Glacier) trade retrieval speed for storage cost, useful for archiving old data cheaply. Worked example: a document-analysis SaaS lets users upload PDFs for AI summarization. The frontend requests a pre-signed upload URL from the backend (`POST /api/uploads/presign` returns a signed S3 PUT URL valid for 5 minutes), the browser uploads the PDF directly to that URL, and only after the upload completes does the frontend notify the backend with the object's key — which triggers a background pipeline job to fetch the file from object storage, extract text, chunk it, and embed it into the vector store. The application server itself never touches the PDF's bytes, keeping upload bandwidth and server load off the app tier entirely. A lifecycle rule automatically deletes the original PDF after 90 days if the user's account is on the free tier, while extracted text and embeddings persist indefinitely — separating the expensive-to-store raw object from the cheap-to-keep derived data it produced.