A memory card that served faithfully in a camera for years can die within months inside an always-on project, and the reason confuses a lot of people. The card is not defective and the board is not to blame. The difference is the pattern of writing. A camera saves a large photo now and then, while a small computer running around the clock dribbles tiny writes into logs and databases every few seconds. Those two workloads age flash storage in completely different ways, and understanding why explains most card failures and points to every worthwhile fix.
Why steady small writes are the problem
Flash memory cannot overwrite data in place. It reads, erases, and rewrites in fixed blocks, and the erase block is much larger than the small chunks an operating system typically changes. When a program updates a few hundred bytes in a log, the card may have to rewrite an entire block behind the scenes, a mismatch called write amplification. A tiny logical change becomes a much larger physical write.
A camera never triggers this. It writes big sequential files that line up neatly with the flash blocks, so almost nothing is wasted. An always-on board does the reverse, scattering frequent small random writes across the card. The controller shuffles data around to spread the wear, but every rewrite spends a slice of the limited erase cycles each cell can survive, and the cheapest cards have the fewest to give.
The write patterns that wear cards out
Two everyday sources cause most of the damage. System logs are the first, since a busy service can append to its log files continuously, and a chatty application recording every event adds up quickly. The second is any local database. Lightweight databases such as SQLite, used by countless home tools, commit changes with small synchronous writes and journal files that update on nearly every operation.
A network ad blocker is a clear example, because it logs every query the household makes and stores them in a database that changes constantly. That workload is gentle on a real disk and harsh on a memory card, a hazard worth weighing before you follow the walkthrough on running a network-wide ad blocker at home.
Moving writes off the card
The most effective fix is to stop writing to the card so often. Volatile data that need not survive a reboot can live in RAM. A common approach mounts the log directory as a tmpfs, a filesystem held in memory, so routine logging never touches the card at all. Helpers that periodically flush an in-memory copy back to storage exist for the logs you do want to keep.
Anything with a real, growing dataset belongs on external storage. A USB solid-state drive, or even a good USB stick, handles constant writes far better than a card and reports its health honestly. Pointing databases and application data at an attached drive, or serving them from a central machine, removes the busiest writes entirely, one of the motivations behind the guide on setting up a home file server.
Common mistakes that shorten card life
Most early failures come down to a small set of preventable habits. The table pairs each with the reason it hurts and a better approach.
| Mistake | Why it wears the card | Better approach |
|---|---|---|
| Logging to the card by default | Constant small appends amplify writes | Send logs to a tmpfs in RAM |
| Running a database on the root card | Journaled commits rewrite blocks often | Move the data to a USB SSD |
| Leaving swap on the card | Memory pressure causes heavy random writes | Disable swap or move it to a drive |
| Buying the cheapest card available | Fewest erase cycles and no health reporting | Fit a rated high-endurance card |
Making the root filesystem read-only
A stronger measure is to stop the system writing to its own root at all. With an overlay filesystem, the base operating system is mounted read-only and every change is captured in a temporary layer held in memory. The card is only read during normal running, and a power cut cannot corrupt it because nothing was mid-write. Many projects offer this as a toggle, and Raspberry Pi OS includes an overlay option in its configuration tool.
The trade-off is that changes vanish on reboot, which is exactly right for a fixed-purpose appliance and inconvenient for a machine you tinker with daily. For a set-and-forget build such as a sensor gateway or an automation controller, a read-only root removes the most common corruption path outright. Some builders drop the card altogether, the approach the guide on booting a board from the network lays out.
What endurance cards really buy you
High-endurance and industrial cards, often sold for dashcams and surveillance, are built for this exact duty. Their real advantage is the flash type and the rated write endurance, quoted as terabytes written or as a lifespan in recording hours. Some use pseudo-SLC flash that stores one bit per cell instead of three, which multiplies the number of safe rewrites at the cost of capacity.
They are not magic. An endurance card postpones failure rather than removing it, and it still gains from every technique above. The fair reading is that a good card buys headroom and predictability, not immunity. Pair one with reduced writes and a build can run for years, and the same board can then take on many roles once storage is handled well, as the survey of practical Pi projects shows.
What this means in practice
Card failure in an always-on build is rarely bad luck. It is the predictable result of a write-heavy workload meeting cheap flash, and every dependable setup treats the card as a component that will wear rather than one that lasts forever. The order of priorities is simple: cut needless writes first, move the busy data to storage designed for it second, and choose a better card third.
Doing all three is not overkill for anything you plan to leave running unattended. A read-only root or a network-served filesystem, logs in memory, a database on a USB drive, and an endurance card together turn a fragile appliance into one you can forget about. The effort is small next to the frustration of a corrupted card at the worst possible moment.
Frequently asked questions
How long does an SD card last in a Pi?
It varies enormously with the workload. A card in a project that barely writes can last many years, while one carrying constant logs and an active database may fail within months. The cheapest cards fail soonest. With writes moved to RAM or a USB drive and a high-endurance card fitted, most people stop replacing cards at all, and the question stops mattering.
How do I stop SD card corruption?
Corruption usually strikes when the card is written to during a power loss. Reduce the risk by moving logs to a tmpfs, putting databases on a USB drive, disabling swap, and shutting down cleanly rather than pulling the plug. A read-only root filesystem removes the danger almost entirely, since the card is never mid-write when the power disappears.
Should I run my Pi read-only?
For a fixed-purpose build you rarely change, yes. A read-only root guards against the most common corruption cause and means an abrupt power cut leaves the card intact. It is less convenient on a machine you experiment with, because edits do not survive a reboot unless you deliberately switch writing back on. Match the choice to whether the device is an appliance or a workbench.
