Features

Flash-Optimised Storage

Traditional databases assume random read/write storage. Flash memory is fundamentally different — erasing a block is orders of magnitude slower than writing, and each block can only be erased a finite number of times (typically 10,000–100,000 erase cycles for NOR flash).

GreatEmbeddo's block layer is optimised for flash storage, but also performs well on other storage media. Wear levelling spreads metadata and data blocks across the device, so that no single block gives out early. All data is checksummed, replicated and distributed to avoid data loss even in extreme situations.

Log-Structured B+Tree Engine

GreatEmbeddo stores data in a log-structured B+tree. Both leaves and internal nodes are written append-only and rewritten only when a block fills, so most updates avoid rewriting whole blocks — ideal for performance and flash endurance.

Transaction Safety

Data loss and corruption are among the most damaging failures an embedded device can experience, and among the hardest to diagnose in the field. GreatEmbeddo is built so that power outages, sudden resets, and mid-write interruptions leave your data intact.

Every write is backed by a replicated log. If power is lost at any point, GreatEmbeddo recovers automatically to the last fully committed state — no manual intervention, no partial writes visible to the application. Readers are never blocked by ongoing writes, which keeps response times predictable even under heavy load.

• Power outages and unexpected resets cannot corrupt the database. Recovery is automatic.
• Writes are all-or-nothing. A failed transaction leaves data exactly as it was before.
• Readers are never blocked. Concurrent reads complete without waiting for writes to finish.
• The replicated log survives partial storage failures. Data remains accessible even when individual blocks go bad.

Schema Versioning

When you update firmware in the field, you need to know exactly which schema version is running on each device — and be confident that a firmware update won't silently open a database it wasn't built for. GreatEmbeddo makes schema versions explicit and tamper-evident, so mismatches are caught at startup rather than causing silent data corruption later.

The schema version is baked into the generated code at build time. If a device's database was written by a different schema version than the running firmware, the runtime refuses to open it and returns a clear error — giving you a safe, predictable failure instead of undefined behaviour.

• Schema version is embedded in the generated code — no runtime configuration required
• Version mismatch is detected at startup, before any data is read or written
• Downgrade protection: newer-schema databases are never silently opened by older firmware
• Pro version supports rolling upgrades, so devices can migrate across schema versions in the field

Code Generation

Integrating a database into an embedded project usually means wrestling with a third-party library, porting it to your toolchain, and hoping it behaves consistently across targets. GreatEmbeddo takes a different approach: it generates plain C99 source files from your schema, which you compile directly into your firmware like any other source file.

There is no runtime library to link, no dynamic allocation, and no OS or filesystem dependencies. The generated code is self-contained and predictable — it behaves exactly the same on every compiler and target it is built for. See the Getting Started guide for the full list of generated files.

• Compiles with -std=c99 on GCC, Clang, IAR, Keil, and Green Hills. No toolchain-specific workarounds required.
• No malloc, no printf, no OS or filesystem dependencies
• Each table gets strongly-typed insert, get, update, delete, and scan functions. Type errors are caught at compile time.
• Memory footprint is fixed at compile time. No surprises on resource-constrained targets.

Replication

Flash blocks wear out and occasionally go bad — especially in harsh environments. If your database has only one copy of its data, a single bad block can make records unreadable or, worse, silently return corrupt values. GreatEmbeddo protects against this by keeping multiple independent copies of your data spread across the device.

When a bad block is detected during a read, GreatEmbeddo automatically repairs it from a healthy copy — transparently, without any action required from your application. Your device keeps running even as individual flash blocks reach end of life.

• Each table's replication factor is set in the schema. Tune the trade-off between storage use and resilience per table.
• Bad blocks are detected and repaired automatically on read. No application-level handling needed.
• The commit log is replicated independently, so the database can reopen even if several log blocks are lost.
• Replication works alongside wear levelling. Copies are spread across different physical locations, not the same area.

Comparison with alternatives