The “just store everything in S3” crowd is getting louder. Companies like Turbopuffer, Neon, and Cursor with its Origin feature are making the case that object storage should be the default home for all your data, analytical, transactional, even operational. On paper, it’s seductive: infinite scale, decoupled compute, pay-per-GB economics, and no proprietary format locking you in. Who wouldn’t want that?
But here’s the thing, people have been saying this for two decades. The signal-to-noise ratio on this debate has always been high, and the reasons are as much about workload types as they are about technology maturity. Before you migrate your entire stack to a single S3 bucket, you need to understand what’s actually changed, what hasn’t, and where the latency boogeyman is still hiding.
The Core Promise: Separation of Storage and Compute
The entire foundation of the “S3 for everything” movement rests on one architectural principle: decouple your storage from your compute. Databricks runs entirely on object storage. Snowflake reads from it. The modern data lakehouse stack, Apache Iceberg, Parquet files on S3, a REST catalog, and pluggable query engines, embodies this philosophy completely.
If you’ve ever worked with a 9PB data lake, you know why this matters. One engineer who spent over a decade building analytical platforms on object storage puts it plainly: the storage layer just sits there, durably, cheaply, while your compute scales up and down independently. You don’t pay warehouse pricing for idle storage. You don’t migrate data when you switch engines.
This is a genuine win for analytical workloads. Columnar formats like Parquet are designed for this pattern. A query touching 3 columns out of 200 only reads those 3 columns. Min/max statistics in row groups let engines skip files entirely. Data moves between systems 10, 90x faster with Arrow-based protocols than with legacy row-based ones. The serialization tax that used to dominate query latency is gone.
But analytical workloads were never the controversy.
The Row-Oriented Elephant in the Room
The real tension emerges when you try to run row-oriented, transaction-heavy workloads directly on S3. This is where the skeptic’s argument gets sharpest, and it’s a valid one.
The latency difference between NVMe/memory and object storage isn’t small. It’s potentially three orders of magnitude. When your working set exceeds the NVMe/memory available to your compute layer, every request that misses the cache pays a penalty of hundreds of milliseconds. For online services, gaming, retail, anything with a latency SLA measured in tens of milliseconds, that’s not a tradeoff. It’s a non-starter.
The engineering community has a name for what happens when you ignore this: you end up sizing your “S3-native” database with enough local NVMe to ensure S3 is never actually hit. At which point, as one sharp observer noted, you might as well just use S3 as your backup and restore layer, because that’s all it’s really doing.
That’s the honest assessment. If you build a system that could access S3 for row-oriented data but architect it to never actually need to, you’ve added complexity without gaining the elasticity benefit.
What Actually Changed: The New Generation of S3-Native Tools
This is where the conversation gets interesting, because the tools mentioned in the original discussion represent a genuine evolution, not just marketing.
Neon (and by extension, Databricks’ acquisition of Neon and the rollout of Lakebase for Postgres) is attacking the row-oriented problem head-on. Lakebase provides a Postgres-compatible interface backed by S3, with compute that can scale to zero. Teams using it for security log workloads report low latency even with that scale-to-zero behavior, the compute just spins up when needed and the data comes from S3.
The key caveat? Those workloads, security logs, event streams, append-heavy data, have very different SLA requirements than your user-facing application database. Nobody notices if a security log query takes 300ms on a cold start. Everybody notices if an e-commerce product page does.
Turbopuffer takes a different approach, using object storage as the foundation for a search engine that’s designed to handle vector workloads at scale. It’s a compelling pattern for AI applications where the bleeding edge isn’t latency but total data volume and cost.
Cursor with Origin has generated buzz for using S3 as the backing store for code search and retrieval. Again, the access pattern matters, these are batched, analytical, or near-analytical workloads, not point-of-sale transactions.
None of these tools are trying to replace a traditional OLTP database. They’re all exploiting the gap between what S3-native architectures can do now versus what they couldn’t do five years ago.
The Latency Math: When It Works and When It Doesn’t
Let’s be concrete about the numbers, because that’s where the debate stops being philosophical.
- Memory latency: ~100 nanoseconds
- NVMe latency: ~100 microseconds
- S3 GET request latency: ~100 milliseconds (cold, first request after compute scales up)
- S3 sustained throughput: 5,500 GET requests per second per prefix
That’s a 1,000x gap between S3 and local NVMe for single-object access. No amount of clever engineering eliminates that. What good engineering does is avoid needing that low latency in the first place.
Columnar analytics
For columnar analytics, S3 is optimal. Parquet’s columnar layout, combined with row-group statistics, means a well-maintained table can skip 90%+ of files before reading a byte. Query planning might touch metadata, but data scanning is efficient and parallelizable. This is why Databricks and Snowflake can run on object storage without sacrificing query performance for typical BI workloads.
Other workload types
For row-oriented point lookups, S3 is still a cold-start latency trap for unpredictable access patterns. If your workload is “get user #12345’s profile” over HTTP, you’d better have that data cached somewhere fast.
For append-heavy, scan-light workloads (logs, events, telemetry), S3-native storage engines like Lakebase work well precisely because they combine the durability of S3 with the compute elasticity to handle intermittent access. Cold start latency on a security log query is fine.
For mixed workloads, some hot data, some cold, unpredictable access patterns, you need a caching layer, a hybrid storage engine that understands which data deserves NVMe and which belongs on S3. That’s where the art lies.
AWS Is Actively Racing Toward Universal S3 Storage
Meanwhile, AWS is not sitting on its hands. The feature blitz around S3 shows where Amazon thinks the market is heading:
- S3 Express One Zone for performance-critical workloads needing single-digit millisecond latency
- S3 Tables for tabular data, with up to 10x higher transactions per second than Iceberg tables in general-purpose buckets
- S3 Vectors for sub-second vector similarity search with up to 90% lower costs than traditional vector stores
- S3 Files for POSIX-compatible access with full file system semantics directly on S3 objects
- S3 Metadata for queryable object metadata with 1GB JSON annotations per object
The message from Amazon is unambiguous: S3 is no longer just a data lake. It’s becoming the substrate for the entire data stack. AWS positions S3 for data lakes, mobile apps, backup, archival, IoT, ML, AI, and analytics, which is to say, everything.
S3 Tables deserves particular attention. Native Apache Iceberg support means you can store tabular data with the same query patterns you’d use in a warehouse, but with object storage economics. This directly attacks the cost structure of traditional warehouses. And with S3 Metadata storing live inventory, journal, and annotation tables in Iceberg format, the line between “storage” and “database” is blurring fast.
The Operational Reality Nobody Mentions
Here’s the uncomfortable truth about the open lakehouse architecture that makes S3-based storage viable: nobody owns the operations.
With a proprietary platform like Databricks or Snowflake, the vendor handles compaction, snapshot expiration, and table optimization. The catch: you’re locked into their stack. With an open lakehouse on S3, you get that independence, but the operational complexities of managing large-scale data lake architectures like Iceberg become your problem.
The degradation is measurable and predictable:
- A streaming job with 10-minute commits creates ~4,300 files per month per table
- Above 5,000 files, query performance degrades noticeably
- Above 20,000 files, you’re in pain
- A 500GB table with 100,000 small files takes 15-30 seconds just for query planning
- The same data in 2,000 properly-sized files plans in under a second
The same data. The same S3 bucket. A 30x difference in query planning time, solely based on maintenance discipline.
Compaction is the highest-leverage operation in a production lakehouse, and most teams are doing it wrong, either with static schedules that don’t match workload patterns or with Spark-based jobs that are so expensive and slow they only run weekly. Smart compaction, driven by actual query patterns and built on a Rust-based engine, reports 95% faster execution and 90% lower cost than Spark equivalents. The compounding effect of query-aware sort ordering means tables that were previously only queryable on Spark become accessible to DuckDB, Trino, and Athena after proper optimization.
If you’re going to adopt the “store everything in S3” philosophy, you’re also adopting the “operate everything on S3” responsibility. Those go together, whether you like it or not.
Where the “Universal Data Lake” Thesis Breaks Down
Despite the enthusiasm, there are clear boundaries to what S3-centric storage can handle.
Transactional systems with high concurrency and strict consistency still need purpose-built databases. S3 provides strong read-after-write consistency, which is a massive improvement, but it’s not a substitute for a distributed transaction coordinator. The REST catalog pattern in Iceberg handles optimistic concurrency, but the coordination overhead is real.
Sub-millisecond latency workloads are impossible on S3. Full stop. If your users are interacting with your application in real-time, your data needs to live in memory or NVMe. Amazon’s own S3 Files feature claims “no compromise” between file and object semantics, but physics doesn’t care about marketing claims.
High-volume point lookups, the kind where you’re serving millions of individual record requests per second, will generate unbearable GET request costs and latency if you try to serve them directly from S3. The request rate of 5,500 GET/s per prefix sounds impressive until you’re doing 50,000 reads per second.
Cost models can invert. Storage is cheap, but retrieval isn’t. S3’s pricing structure means that scan-heavy workloads can rack up egress and request charges that dwarf the storage cost savings. This is why data warehouse → lake → lakehouse evolution hasn’t eliminated the need for cost-aware query routing.
S3-Compatible Storage: The Standard Framework
The S3 API itself has become the lingua franca of unstructured data infrastructure. As Scality’s comparison of S3-compatible solutions notes, the API has been so widely adopted that applications built for S3 can work across compatible platforms without redesigning access patterns.
That’s an underappreciated aspect of the “store everything in S3” trend. Even if you never touch AWS, the S3 API is the common interface for object storage everywhere, Scality, Cloudian, MinIO, Ceph, all public clouds. The de facto standard means your data isn’t actually locked into AWS at all.
| Solution | Deployment model | Strong fit | Key consideration |
|---|---|---|---|
| Scality | On-prem/hybrid/software-defined | Enterprise storage, backup, AI | Multiple products for different scales |
| Cloudian | On-prem/hybrid | Enterprise S3 object storage | Primarily S3-focused |
| MinIO | Software-defined/cloud-native | Kubernetes and developer environments | Evaluate operational model for enterprise |
| Ceph | Open source/software-defined | Object + block + file | Requires significant operational expertise |
| Public cloud | Cloud-native | Elastic consumption | Watch egress and retrieval costs |
The durability, security, and immutability features, Object Lock, versioning, encryption, lifecycle policies, make S3-compatible storage the default choice for backup and compliance workloads regardless of whether you’re building a “universal data lake.”
The Verdict: Not Universal, But Unstoppable
Is S3 becoming the universal data lake? Yes, but with asterisks.
It is becoming the universal storage layer, the durable, scalable, cost-effective foundation for everything from backup archives to AI training data. The S3 API is the standard interface, and the feature set (Tables, Vectors, Metadata, Files) is evolving to handle workloads that historically required proprietary systems.
It is not becoming the universal compute layer. Latency physics, concurrency models, and cost structures ensure that transactional, real-time, and point-lookup workloads will always need purpose-built engines with local data access. The high-bandwidth storage breakthroughs challenging traditional memory hierarchies will narrow the gap, but the architectural distinction remains.
The smartest strategy, emerging from the experience of teams running production workloads on both patterns, is a gradient approach:
- Analytical data (Parquet tables, Iceberg format) → S3 directly
- Hot transactional data (user-facing, sub-100ms SLA) → NVMe/SSD-backed databases with S3 as backup
- Warm row-oriented data (logs, events, moderate access frequency) → S3-native storage like Lakebase, with compute that scales from zero
- Archives and compliance data → S3 Glacier classes with lifecycle policies
The teams that treat S3 as a universal destination rather than a universal substrate are the ones that succeed with this pattern. They store everything in S3, but they don’t serve everything from S3.
That’s the nuance the “just store everything in S3” hype misses. The storage decision is only half the architecture. The compute strategy, where data lives, how it’s accessed, when it moves, is where the real engineering happens.
As for whether it’s “worth the latency”, the only honest answer is: it depends on what you’re trying to serve and who’s waiting for the response. For a security log query at 3 AM? Absolutely. For a shopping cart checkout? Not a chance, unless you enjoy angry customers and support tickets. The trend is real, the tools are improving, but physics still works exactly the way it did before the hype cycle started.