Summary: Two major storage announcements in 2026 (Amazon S3 Files and Hugging Face Buckets) reveal how the industry is racing to close gaps between objects, files, and AI-native workflows. At Pixeltable, we've been watching this closely, because the friction these announcements address is exactly what we set out to eliminate. This post unpacks what changed, why it matters, and how Pixeltable's approach compares.
The Data Friction Problem#
Andy Warfield, VP and Distinguished Engineer at AWS, opened his post on S3 Files with a story about sunflower DNA researchers at UBC. The biologists had tools that expected a local Linux filesystem. Their data lived in S3. The result was an endless loop of copying data back and forth, managing inconsistent copies, and writing infrastructure instead of doing biology.
Warfield calls this data friction:
"S3 was great for parallelism, cost, and durability, but every tool the genomics researchers used expected a local Linux filesystem. Researchers were forever copying data back and forth, managing multiple, sometimes inconsistent copies. This data friction (S3 on one side, a filesystem on the other, and a manual copy pipeline in between) is something I've seen over and over in the years since."
This isn't an edge case. Anyone building multimodal AI applications (processing video, images, audio, documents) hits this wall. Your training scripts expect local file paths. Your embeddings live in a vector database. Your metadata sits in Postgres. Your raw assets are in S3. And you, the builder, are the glue code.
S3 Evolves: Tables, Vectors, and Now Files#
What makes the S3 Files announcement remarkable is that it's the culmination of a multi-year pivot for S3 itself. Over the past two years, the S3 team has shipped three new first-class data primitives beyond objects:
| Primitive | What It Does | Launched |
|---|---|---|
| S3 Tables | Managed Apache Iceberg tables with automatic compaction and cross-region replication | re:Invent 2024 |
| S3 Vectors | S3-native vector indexes: elastic, pay-per-use similarity search anchored on S3's durability profile | re:Invent 2025 |
| S3 Files | Mount any S3 bucket as a network filesystem (backed by EFS) on EC2, containers, or Lambda | April 2026 |
The thesis is clear: object storage alone is no longer enough. Different workloads need different access patterns (tabular queries, vector similarity search, POSIX file operations), and forcing everything through a single object API creates friction that slows builders down. This is the same fragmentation we explored in our AI database landscape guide.
Warfield put it well:
"As the cost of building applications collapses, and as each application we build can serve as a reference for the next one, it really feels like the code/data division is becoming more meaningful than it has ever been before. We are entering a time where applications will come and go, and as always, data outlives all of them."
The "Stage and Commit" Boundary#
The most fascinating design decision in S3 Files is what the team calls stage and commit, borrowed from git. Rather than trying to make file and object semantics invisible (which they tried and failed to do), the team embraced the boundary between the two modalities as a first-class feature.
Files are rich, mutable, OS-native constructs. Objects are immutable, durably stored, and built for massive parallelism. Trying to collapse that distinction leads to what one engineer on the S3 team called "a battle of unpalatable compromises."
Instead, S3 Files presents both views of the same data:
- Mount a bucket → work with files using standard Linux tools, NFS semantics, directory operations
- Changes accumulate in the file layer (EFS) and are committed back to S3 roughly every 60 seconds
- S3 remains the source of truth; conflicts are detected and flagged
- Lazy hydration means you can mount a bucket with millions of objects and start working immediately
This is an honest design. As Warfield notes: "We spent months trying to make [the boundary] disappear, and when we finally accepted it as a first-class element of the system, everything got better."
Hugging Face Buckets: Storage for the ML Crowd#
While Amazon tackles the file-vs-object divide, Hugging Face is solving a different storage friction: git doesn't scale for large mutable artifacts.
Hugging Face's entire ecosystem (models, datasets, Spaces) is built on git-based repositories with LFS for large files. That works brilliantly for versioned model weights and curated datasets. But it breaks down for the messy middle ground of AI development: training checkpoints, intermediate artifacts, logs, scratch data that changes constantly and doesn't need version control.
Hugging Face Buckets fills this gap with S3-like object storage on the Hub, powered by their Xet storage backend with content-addressable deduplication. No git history, no LFS overhead, just fast, mutable storage with a simple CLI and Python API:
The hf buckets sync command is particularly telling. It's essentially rsync for the Hub, with filtering, dry-run planning, and incremental transfers. This is infrastructure that ML teams have been building ad-hoc with custom scripts for years. (Julien Chaumond, HF CTO, walked through the rationale on YouTube.)
The Pattern: Storage Is Fragmenting, Not Converging#
Step back and look at the trend line:
- S3 is adding tables, vectors, and files alongside objects: four data primitives in one system
- Hugging Face is adding mutable bucket storage alongside git-based repositories
- Every vector database (Pinecone, Weaviate, Qdrant) is adding metadata filtering and hybrid search
- Every relational database (Postgres, MySQL) is adding vector extensions
Everyone is converging toward the same realization: multimodal AI workloads need multiple storage modalities, and the boundary between them is where all the pain lives.
S3's answer is new primitives. Hugging Face's answer is new storage types. Vector DBs are adding SQL-like features. SQL databases are adding vector features. Each tool is growing tentacles toward the others.
But there's a deeper question: who owns the unified abstraction?
How Pixeltable Approaches This Differently#
Pixeltable's premise, from the beginning, has been that the right abstraction isn't at the storage layer. It's at the declarative data layer. Storage is an implementation detail. What matters is how you interact with your data: define it, transform it, query it, search it. We detailed this philosophy in our architecture overview and the deployment guide.
Here's what that looks like in practice. This single table definition handles what would require S3 + Postgres + a vector database + an orchestrator like Airflow in a traditional stack:
No S3 client library. No vector database SDK. No Airflow DAGs. No sync scripts. The video can live on local disk, an S3 bucket, or a URL. Pixeltable handles it transparently. To understand the four-layer storage architecture that makes this possible, see our deep dive.
Storage Transparency: Why Pixeltable's Approach Differs from S3 Files#
The S3 Files team spent months trying to make the boundary between files and objects invisible, and ultimately concluded the boundary itself should be explicit. That's the right call for a storage system. The two modalities have genuinely different semantics.
But when you're building an AI application, you don't want to think about storage modalities at all. You want to think about data: this is a video, this is its transcript, these are its frames, here are the embeddings, here's the LLM summary. Where the bytes live is irrelevant to your application logic.
Pixeltable makes storage a configuration concern, not an architectural decision:
This is what we mean by unifying storage, orchestration, and retrieval. The three concerns aren't separate systems with boundaries between them. They're facets of a single declarative interface.
What the S3 Announcement Gets Right#
We want to be clear: the S3 Files announcement is excellent engineering and sharp product thinking. Several ideas resonate deeply with how we think about data infrastructure:
- "Data outlives applications." Warfield's observation that the code/data division is becoming more meaningful as application development accelerates is exactly right. Pixeltable's versioning and time-travel capabilities are built on this premise: your data and its full lineage persist across application changes. See also audit-ready AI compliance for why lineage matters in regulated industries.
- Lazy hydration. S3 Files only pulls file data when accessed, with metadata imported first. Pixeltable does the same: media columns store references (paths, URLs), and actual file content is fetched and cached on demand. This is crucial for working with large datasets without exhausting local storage.
- The boundary is the feature. Rather than hiding complexity, making it explicit and manageable is a better design. Pixeltable's computed column dependency graph makes every transformation boundary visible and auditable. You can trace any output back to its source data. This is also the foundation of incremental computation: only recompute what changed.
- Agents amplify data friction. Warfield notes that agentic tools default to filesystem interactions and struggle with S3. This is a critical insight. Pixeltable's agent infrastructure and stateful agent memory let LLMs interact with multimodal data through MCP servers and tool-calling, no filesystem hacks needed.
What This Means for AI Builders#
If you're building multimodal AI applications today, here's the practical takeaway:
S3 Files and Buckets Are Infrastructure Wins#
S3 Files eliminates the copy-back-and-forth pattern for tools that need filesystem access. Hugging Face Buckets gives ML teams a sensible home for mutable artifacts. Both reduce friction at the storage layer.
But Storage Alone Doesn't Solve the Application Problem#
Even with S3 Files, you still need to: define schemas for your multimodal data, orchestrate transformations (transcription, embedding, summarization), maintain vector indexes, handle incremental updates when data changes, and manage the dependency chain from raw media to final output. That's the Frankenstein stack problem, and no amount of storage innovation solves it alone.
The Abstraction Needs to Move Up#
The right layer to unify isn't storage. It's the data interface. When you say videos.add_computed_column(transcript=...), you're declaring intent. Pixeltable handles the where (storage), the when (orchestration), and the how (retrieval) behind that declaration. The infrastructure becomes invisible. This is the core thesis of declarative vs. imperative AI pipelines.
Side-by-Side: Traditional Stack vs. Pixeltable#
Here's what a video processing pipeline looks like with and without Pixeltable, now that S3 Files exists:
| Concern | S3 Files + Traditional Stack | Pixeltable |
|---|---|---|
| Store video | Upload to S3, mount via S3 Files | pxt.Video column: local, S3, or URL |
| Extract audio | ffmpeg script reading mounted files | extract_audio(t.video) computed column |
| Transcribe | Whisper API call + result storage in Postgres | transcriptions(audio=t.audio) computed column |
| Embed frames | Frame extraction script + CLIP + Pinecone upsert | add_embedding_index('frame', embedding=clip) |
| Search | Pinecone query → S3 lookup → join metadata | t.frame.similarity(string='query') |
| New data arrives | Trigger Lambda → re-run pipeline steps | Insert row → all computed columns update automatically |
| Lineage | Custom logging across 4+ systems | Built-in dependency graph with time travel |
The left column is better than it was before S3 Files, but it's still 5+ systems, each with its own SDK, failure modes, and sync logic. The right column is one Python import.
Looking Forward#
The storage landscape is evolving fast. S3 adding four data primitives in two years is a signal that the biggest cloud provider in the world sees multimodal data access as a first-order problem. Hugging Face building purpose-built bucket storage shows the ML community needs infrastructure beyond git repos. These are validating moves.
But we believe the most impactful abstraction isn't a better storage system. It's a system that makes storage irrelevant to your application code. That's what unifying storage, orchestration, and retrieval under a single declarative interface means. It's what computed columns, multimodal types, and embedding indexes give you out of the box.
S3's evolution proves the problem is real. Pixeltable proves the solution doesn't have to be complicated.
Get Started with Pixeltable#
Ready to stop building glue code?
- Pixeltable Starter Kit: production-ready FastAPI + React app with multimodal upload, cross-modal search, and tool-calling agents
- Documentation: full API reference, tutorials, and deployment guides
- Your First Pixeltable Project: step-by-step beginner tutorial
- Core Concepts: tables, computed columns, views, and embedding indexes explained
- Deployment Overview: choose the right deployment strategy for your use case
- GitHub: star the repo, file issues, and contribute
Further Reading#
Dive deeper into the topics covered in this post:
- The Triforce of AI Infrastructure: Storage, Orchestration, and Retrieval
- Understanding Pixeltable's Four-Layer Storage Architecture
- Deconstructing the AI Frankenstein Stack
- The Economics of Incremental AI
- Video Intelligence Pipeline Tutorial
- Multimodal RAG in Production
- Iterate on Data, Not Infrastructure
