Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to writeup reduces the storage choice to a property test on the calling code. The part worth arguing about is when each wrong answer shows up: on the first query, or at 10 million files.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The useful part of this comparison is not the requirement lists, it is when each mistake becomes visible. Put a database on object storage and the error reports itself early: the dev.to writeup by Ethan Carter puts object latency at millisecond level with no in-place mutation [6], against the sub-millisecond random reads, in-place byte updates, ordered fsync and lock files that PostgreSQL, MySQL, MongoDB and SQLite expect from a filesystem or block device [7]. Two of those four properties are precisely the ones object storage does not have [2]. Put user photos on an ext4 volume instead and nothing reports anything at all until inodes run out [9]. One error costs you a slow afternoon in development. The other costs an afternoon two years later, on a volume somebody else provisioned.
The two anecdotes in the post are the same workload an order of magnitude apart. The filesystem falls over around 10 million files [1]; the bucket holding the same photos reached 100 million [2], a 10x gap on identical data [1]. And the object path got there without a code change [11], which tells you where the migration work lives. It is not on the side that scaled.
So the test runs against the caller, not the data. The operating system opens, reads, writes and seeks; it does not issue HTTP PUTs, and Carter's advice is not to fight that [8]. His own shorthand is that random writes and file locks mean file storage, while HTTP PUTs and billions of objects mean object storage [10]. Uploads, data lake Parquet, backups and ML checkpoints all sit on the object side of his list [4], and none of them call seek(). Shared design files over SMB, build trees over NFS and enterprise home directories sit on the other side because they need directory browsing, file-level permissions and application transparency [17].
He also says most mature stacks run both side by side [5], which makes this a per-path decision rather than a per-company one. The lakehouse exception fits that reading: Iceberg and Delta are named as the niche where things do work over object storage [6], and that is a table format built for object semantics, not a database talked into them.
The hedge is a mount, and the writeup is careful about it. You can get filesystem semantics over S3-style storage, Carter says, but the mount layer will lie to you in small ways [14]. RustFS, whose documented feature table covers S3 core, versioning, bucket replication, event notifications and bitrot protection, ships no FUSE driver at all [15]. If your plan for the POSIX requirement you have not fully specified yet is "we will mount it", that plan depends on a component the server you picked may not offer.
This is one practitioner's checklist rather than a benchmark, and the only latency figures on offer are "sub-millisecond" and "millisecond-level" [3][6]. It is still enough, because the answer does not turn on how many milliseconds. It turns on whether anything in the path mutates bytes in place.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author says he has watched teams try to stretch a filesystem to 100M objects and that inode exhaustion is not a fun afternoon.
The post says terabyte-scale ML workloads are almost always object-storage-backed in 2026, covering training data, checkpoints, immutable dataset versions and Parquet feature stores queried via the S3 API.
The post's short answer: use file storage when you need POSIX semantics, which it defines as in-place edits, sub-millisecond random I/O and file locking (databases, OS files, NFS shares).
The post says to use object storage when you need scale, an HTTP API and rich metadata, listing user uploads, data lakes, backups and ML datasets as the workloads.
The post states that most mature stacks run both storage paradigms side by side.
The post says object storage has millisecond-level latency and no in-place mutation, and that databases on S3 perform terribly with niche exceptions like Iceberg/Delta lakehouse patterns.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One practitioner post, no measurements
Every claim in the cluster comes from a single dev.to article by one author. The technical rules are consistent with mainstream storage practice and the article is internally coherent, but the load-bearing numbers (server falling over at 10M files, 100M files in a bucket, a crossover near 100K files or 1TB, ML 'almost always' object-backed in 2026) are recollections and assertions with no benchmark, telemetry or citation. The only externally checkable references are documentation pointers, the RustFS README feature table and the s3fs-fuse note on slow directory listings, and neither is corroborated by a second source in this cluster.
No adoption events in the cluster
The cluster contains no release, deployment, benchmark, pricing, licensing or usage-disclosure event. The article references workloads and products generically (S3, CloudFront, Spark, Trino, DuckDB, RustFS) and one README feature table, but supplies no counts of users, installations, migrations or measured production usage, so adoption cannot be scored without inventing facts.
Confident thresholds outrun the evidence
The direction of the advice is conventional and the post volunteers real limits, conceding lakehouse exceptions, warning that mount layers lie in small ways, and correcting a capability claim about the one project it names. That restraint keeps the gap small. It is still positive because specific thresholds and prevalence verdicts (10M files as a failure point, 1K-to-100M without code changes, crossover at 100K files or 1TB, ML almost always object-backed) are delivered as settled facts on the strength of anecdote alone, and the cost argument for tiering is asserted without a single figure.
Low-stakes practitioner post, one named project handled deflationarily
Observable incentives are modest: a personal developer-platform post whose reward is attention and credibility rather than a disclosed commercial interest. The only storage project named is RustFS, and it is treated by subtracting a capability (no FUSE driver, no POSIX mount in the README feature table) and explicitly rebutting anyone who claims otherwise, which runs against a promotional motive. Scored above zero rather than near it because the post's insider framing of RustFS documentation is unexplained and the article carries no disclosure of the author's relationship to any vendor, so the reader cannot rule out an affiliation.
Coherent but uncorroborated single source
Confidence is limited by structure, not by contradiction. One publisher, one author, zero adoption events and no second account of any figure means nothing in the cluster can be triangulated. The assessment is more than a coin flip because the post is internally consistent, its qualitative rules align with widely documented storage behaviour, and its two document-based citations are specific enough to be checked. The quantitative claims and the 2026 prevalence statements should be treated as unconfirmed.
build
Once the question needs a cube, you own the parser1 distinct publisher
build
DuckDB is growing a server, and someone on your team will have to run it1 distinct publisher
build
Iceberg won the table format war, then left the maintenance layer to you1 distinct publisher
product
Cloudera bets the agentic AI bottleneck is where the data sits, not which model runs1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026