What microSD Card Should I Buy for IoT Data Logging? A Buyer's Guide

TL;DR

For IoT data logging, buy the smallest capacity that covers your retention window with margin, formatted with the file system your firmware already supports, and pin that exact part number, controller family and formatting procedure in your BOM. Capacity is the cheapest thing to get wrong and the most expensive to fix in the field: a logger that writes 2 MB per day does not need 256 GB, and a logger that writes 200 MB per day will destroy a consumer card’s endurance long before it runs out of space.

Three decisions drive the whole purchase:

1. Capacity band — set by retention days × daily write volume, not by what is on promotion.
2. File system — set by your host firmware and OS, and it must never change silently between production lots.
3. Card behaviour under power loss and heat — set by the controller and firmware, which you cannot see on a datasheet and must qualify on your own hardware.

Everything else — speed class, brand, packaging — is secondary for this segment.

Why IoT loggers are a different buying problem

Most microSD buying advice is written for cameras and phones, where the workload is large sequential bursts and the user notices a dropped frame. A data logger is the opposite: small, frequent, append-only writes, often into a single growing file, on a device nobody looks at for months, powered by a supply that may brown out.

That changes what matters:

• Endurance is consumed by write amplification and metadata updates, not by capacity used.
• Power-loss behaviour decides whether a bad shutdown costs you one record or the whole file system.
• Thermal behaviour matters if the logger sits in an enclosure with no airflow, because sustained writes and elevated temperature interact.
• Traceability matters because when a batch of loggers comes back with unreadable cards, you need to know whether it was one flash lot, one controller, or one firmware build.

None of these are captured by the U3/V30/A2 labels printed on retail packaging.

The capacity band: how to size it properly

Step 1 — Measure daily write volume, not card size

Take the record size, the record rate, and any index or metadata overhead, then multiply. A logger writing one 512-byte record per second is writing roughly 44 MB per day before overhead; the same device writing one record per minute is writing under 1 MB per day. Those two devices should not be buying the same card.

If you are still at the design stage, use the TF card capacity estimator to sanity-check the arithmetic before you commit to a band.

Step 2 — Multiply by retention days and add margin

Retention is a product decision (how long must data survive on the device before upload or service visit?), not a storage decision. Once you have it, add margin for:

• the file system’s cluster slack on small records,
• the fact that a nearly-full card writes more slowly and wears faster,
• and the field reality that some units will not be serviced on schedule.

A common rule of thumb is to size for at least 1.5× the nominal requirement, then round up to the next band your supplier actually stocks. (Illustrative only — not WINTEL data: a logger writing 20 MB/day with a 180-day retention target needs about 3.6 GB, so an 8 GB card gives comfortable headroom; the same logger with a 3-year retention target needs about 22 GB, which pushes into 32 GB.)

Step 3 — Stop at the point where capacity stops helping

Above a certain point, more capacity does not extend life — it just means the card is emptier when it fails. The trade-offs between adjacent bands, and where the market stops making economic sense for a given use, are covered in capacity bands: where they stop making sense.

Also remember that capacity is not a constant across temperature. If your logger runs hot or cold, read capacity drift across temperature before you finalise the retention maths.

The file system: pin it or it will bite you

FAT32 — the default, with a hard ceiling

FAT32 is what most microcontroller file system libraries expect, and it is the safest choice for a device with a small RTOS and no journaling. Its limits are well documented: a 4 GB maximum file size and volume-size constraints that push you toward large clusters on big cards, which wastes space on small records. Microsoft’s own documentation on maximum file size is the reference to cite internally.

If your logger writes one continuous file and your retention window exceeds 4 GB of records, FAT32 will fail you — not at the card level, but at the file level.

exFAT — better for long single-file logs

exFAT removes the 4 GB file limit and scales cluster size sensibly on large volumes. Microsoft publishes the exFAT specification, which is worth reading if you are implementing your own writer. The catch is host support: confirm your RTOS or bare-metal library actually implements exFAT correctly, including the directory entry updates that happen when a file grows. A partially implemented exFAT writer is worse than FAT32.

ext4 and F2FS — for embedded Linux loggers

If the device runs Linux, you are not limited to FAT. ext4 with journaling gives you crash consistency at a known cost in write amplification; see the kernel ext4 documentation. F2FS was designed for flash-backed storage and is documented in the kernel F2FS documentation; it is often a better fit for append-heavy logging on NAND, but it is a deliberate engineering choice, not a default.

Whichever you pick, write it into the BOM alongside the card part number. Field reformatting is one of the most common causes of “the card died” reports, and it is almost always a file-system mismatch rather than a hardware failure.

What your equipment will and will not accept

Interface mode

Not every logger host speaks full SD mode. Many microcontrollers only implement SPI, which caps throughput well below what the card is capable of. If that is your design, the ceiling is set by the bus, not the card — see microSD SPI mode throughput ceiling and SPI mode vs SD mode interface selection.

Application performance class

A1 and A2 are defined by the SD Association’s application performance class specification. They describe random IOPS, and A2 additionally requires host support for command queueing. For a sequential append logger, they are a weak signal. The fuller explanation is in microSD A1/A2 application performance.

Power-loss behaviour

This is the one that decides field failure rates, and it is not on any datasheet. The card’s controller decides when metadata is committed, and different controllers behave differently when power disappears mid-write. Read microSD card power-fail safe write strategy and power loss corruption and what protects data before you write the qualification plan, and test on your own host with your own supply.

Thermal envelope

A sealed enclosure with no airflow will run warmer than the bench. If your logger writes continuously, read microSD card heat sink and thermal throttling and plan a thermal soak test into qualification.

What to lock in the BOM

The BOM line for a logger card should be more specific than “microSD 16 GB”. At minimum, lock:

• Capacity and tolerance — the exact band, and whether a substitute band is acceptable (usually it is not, because it changes the formatting and test plan).
• Controller family — not necessarily a brand name, but a commitment that the controller will not change without notice. Controller substitution is the classic cause of “same part number, different behaviour”.
• Flash lot traceability — so that a field failure can be traced to a die lot. The mechanics are described in flash memory lot traceability and die marking.
• Pre-formatting and pre-loading — whether the supplier formats the card to your file system and writes your image before packing. WINTEL offers pre-loading as a service on custom flash products; the general process is described in microSD image flashing at volume.
• Label and marking — including any variable data such as serial numbers, which is covered in different names on each unit.
• Packaging — reel, tray, or bulk bag, and whether the packaging is part of the acceptance criteria.

For the card form factor itself, the product page at /products/tf-card/ lists the configurations WINTEL builds; if your logger is a board-level design rather than a removable-card design, compare against /products/udp/ and read card vs module: not interchangeable before assuming a socket.

Purchase-order checklist for IoT data-logging cards

Work through these in order. Each one exists because skipping it has a known failure mode.

1. State the workload, not just the capacity. Put daily write volume, record size, write pattern (sequential append vs random), and expected duty cycle on the PO or its attachment. A supplier who only receives “16 GB microSD” cannot flag a mismatch, and you will not find out until the field does.

2. Name the file system and the formatting procedure. Specify FAT32, exFAT, ext4 or F2FS explicitly, and say who formats — supplier before packing, or your own line. If the supplier formats, require a sample to be verified on your host before the run starts.

3. Pin the controller and require written notice of change. A part-number-only PO lets a supplier swap controllers mid-program. Ask for a change-notification clause; the reasoning is in flash brand and controller pairing.

4. Require lot traceability on the reel or bag label. Lot or date code, capacity, and the supplier’s internal part number should be readable without opening the packaging.

5. Define the power-loss acceptance test. Write down how many units you will pull from the first article, how you will interrupt power mid-write, and what counts as a pass. This is the single most valuable test for this segment, and it must be agreed before production, not after.

6. Agree the sample and first-article process. Use the sample acceptance checklist as the basis, and read flash sample fee and what to test on one so you know what a sample fee is buying.

7. Fix the packaging and labelling spec. Reel orientation, label content, and any serialisation. If the cards go straight into a production line, packaging errors cost more than card defects.

8. Agree the acceptance criteria and the certificate of conformance. What the CoC will state, and what you will do if a lot fails. See certificate of conformance: what it says.

9. Confirm the delivery date against your build schedule, not the calendar. Working back from a date is a separate discipline; I need these by the 15th walks through it.

10. Agree payment terms and currency exposure. Deposit schedule and any currency clause should be settled before the PO is issued; see how much deposit and currency clauses.

If you are still choosing a supplier, how to tell a real Chinese flash factory from a trading company is the relevant read before you send an RFQ.

Where WINTEL fits — and where it does not

WINTEL (Shenzhen Wintel Digital Technology Limited) manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM/ODM buyers. The company’s published figures are 200+ employees, a 5,000 m² factory, 500,000+ units per month of production capacity, and exports to 50+ countries, with SGS, RoHS, CE and FCC listed among its qualifications.

What that means for this segment, stated plainly:

• WINTEL builds custom configurations to order, including pre-formatting and pre-loading, which is what a logger program needs.
• WINTEL does not publish speed classes, endurance ratings, TBW figures, or operating temperature ranges as standard claims. If your design depends on any of those, they must be specified and verified for your specific configuration — do not assume them from a catalogue.
• MOQ, lead time and pricing are quoted per configuration, not published, because they depend on capacity, controller, pre-loading and packaging.

If your requirement is a standard retail card bought off a shelf, a distributor is the right channel. If it is a configured card with your file system, your image and your label, request a quote with the workload details from step 1 above.

FAQ

Is a “high-endurance” microSD card required for IoT data logging? It depends on write volume, not the label. Endurance ratings are vendor-specific and measured under different conditions, so compare them only as a rough ordering. For low-rate logging a standard card is often adequate; for continuous multi-MB-per-minute writes, endurance and power-loss behaviour matter far more than headline speed. Ask for the endurance test basis, and design the firmware so a card failure loses minutes, not months, of data.

Should I use FAT32 or exFAT on a logger card? Use whatever your firmware and host OS support natively. exFAT removes the 4 GB per-file limit and handles large volumes without tiny clusters, which suits long single-file logs. FAT32 is simpler and has the widest compatibility on microcontrollers and RTOS file system libraries. On embedded Linux, ext4 or F2FS may be the better fit. Pin the choice in the BOM, because field reformatting is a common cause of “card failure” reports.

Does an A1 or A2 rating tell me anything about logging performance? Only indirectly. A1/A2 describe random IOPS under the SD Association’s application performance class definitions, written with app-launch workloads in mind. A data logger writing sequential append-only records is a different pattern. A2 cards also require host support for command queueing to deliver their rated behaviour. Treat A1/A2 as a tiebreaker, not a selection criterion.

How do I stop a power cut from corrupting the log? You cannot stop it entirely at the card level, but you can make it survivable. Use a journaling or log-structured file system, append rather than rewrite in place, fsync at a cadence your data-loss tolerance allows, and keep a small battery or supercapacitor to finish the current write. Then verify the card’s actual behaviour on your own host — that is a qualification test, not a datasheet line.

Can I buy IoT logger cards in mixed capacities in one order? Usually yes, but capacity mixing affects pricing tiers and test time, so raise it early. WINTEL’s published production capacity is 500,000+ units per month, and orders are quoted per configuration rather than per “card” — so a mixed-capacity purchase order should state each capacity, each firmware and file-system image, and each label variant as separate line items.

Sources

• SD Association — SD Specifications, Part 1 Physical Layer: https://www.sdcard.org/downloads/pls/ (accessed 2026-10-29)
• SD Association — Application Performance Class: https://www.sdcard.org/developers/sd-standard-overview/application-performance-class/ (accessed 2026-10-29)
• SD Association — Capacity (SDHC/SDXC/SDUC): https://www.sdcard.org/developers/sd-standard-overview/capacity-sd-sdhc-sdxc-sduc/ (accessed 2026-10-29)
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification (accessed 2026-10-29)
• Microsoft Learn — Maximum file size (FAT32 limits): https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-size (accessed 2026-10-29)
• Linux kernel documentation — ext4: https://docs.kernel.org/filesystems/ext4/index.html (accessed 2026-10-29)
• Linux kernel documentation — F2FS: https://docs.kernel.org/filesystems/f2fs.html (accessed 2026-10-29)