Technical Brief
AltSql Core on one page, for engineers who want to judge whether it fits a device before asking for the full Alpha report. Every figure comes from the Alpha: measured on a PC, with the flash chips and links simulated, or computed where it says so. The engine compiles for four microcontroller families, and its size was measured on each, but it has not run on a microcontroller yet.
What It Is
One C file of 3,907 lines, in C99. A device gets a small build and a gateway gets a full one, and both keep the same records, byte for byte. The caller gives the engine one block of RAM at start-up, and the engine never calls malloc.
| Build | What it holds | Code on a Cortex-M4, compiled |
|---|---|---|
| Key-value | Settings and state | 7,218 bytes |
| Sensor | Key-value, time-series and sync | 14,954 bytes |
| Gateway | Everything, with SQL | 38,122 bytes |
AltSql’s own code and constant data, clang 18 at -Os. Finished firmware also needs a few C library functions and the compiler’s floating-point helpers. The Alpha results give the figures for the Cortex-M0+, M33 and RISC-V.
What It Supports
| Part | What the Alpha does | Limits |
|---|---|---|
| Flash | Any NOR-style flash, through four driver functions | Sectors of 256 bytes or more, a power of two, at least 4 of them; writes aligned to 1, 2, 4, 8 or 16 bytes |
| Key-value | Put, get, delete, list | Keys of 1 to 200 bytes; a key and its value fit in one record, 256 bytes by default |
| Time-series | Declare, append, scan a time range, window statistics on the device | Up to 16 columns; no empty (NULL) values |
| SQL, on the gateway | SELECT with WHERE, GROUP BY, HAVING, ORDER BY, LIMIT and OFFSET; INSERT; CREATE TABLE | No JOIN, UPDATE, DELETE, subqueries, DISTINCT, IN, CASE, indexes or transactions |
| Sync | Device to gateway; resumable; filtered; messages from 51 bytes | One device per gateway copy; no authentication or encryption yet |
| Threads | One caller at a time | No locks inside the engine |
Memory
The engine takes a fixed part of the RAM it is given: 232 bytes, plus 16 per flash sector, 8 per key slot, 44 per series and one record buffer. On the three demo devices that came to 672 to 1,048 bytes. The deepest stack a sensor build needs is 1,376 bytes, measured for a Cortex-M4, so a sensor should budget about 2.5 KB of RAM for the engine. SQL needs about 4.3 KB of stack for ordinary statements, which is one reason it lives on the gateway.
Power Cuts
A record counts only once its checksum is complete, and records are never written over, apart from the first bytes of a sector being retired. A sector is erased only just before it is reused, and reclaiming finishes before anything is retired. After a power cut the engine rebuilds its view by scanning the log: every acknowledged write is there, and the write that was in progress is either whole or absent. In one test run the simulated power was cut 400,000 times with nothing saved lost.
Sync
The device hands out its records exactly as stored, in messages of whatever size the link allows, from 51 bytes up. The gateway checks each record and appends it unchanged. Sequence numbers make a resend harmless, so a lost message is simply sent again. A filter chooses what travels, such as only summaries and alerts. A delete stays on the device until the gateway confirms it.
Storage
A reading with one value takes 26 bytes: a 12-byte header, then the series, the time and the value. In a benchmark with three-column rows, AltSql used 32.3 bytes a row against SQLite’s 22.9. The header pays for the power-cut safety and the sequence numbers that sync relies on.
Known Limits
- Not on hardware yet. Every size above is compile-only, and every test ran in simulation. The Beta measures it all again on real boards.
- Sync is not secure yet. A gateway trusts any correctly formed record. Authentication and encryption get a design in the Beta and code after it.
- Several gateways. A device remembers only the most advanced gateway’s position, so with several gateways a lagging one can miss a delete.
- Flash wear depends on the set-up. One reading a second into 64 KB of 10,000-cycle flash would wear it out in about nine months (computed). Storing summaries, or using external NOR flash, stretches that to years.
- Against the alternatives. SQLite is far more capable and far more tested, and FlashDB is smaller and already proven on chips. AltSql’s case rests on doing both jobs with one format and one sync, so far shown in simulation only.
The Six Prototypes
Around AltSql Core sit six prototypes, each in one C file of 931 to 1,923 lines, each with its own tests and live demo, all in simulation so far. AltSql Ask asks a fleet one SQL question, Vector matches vibration fingerprints, Wave keeps raw bursts searchable, Mesh shares a table with no gateway, Realtime bounds every write for a control loop, and Instant stores on MRAM and FRAM. The engines page says how each relates to Core.
Going Further
The Alpha results have every figure in detail. The Alpha reports go to device makers and investors on request, and the pilot page says how to take AltSql Core onto your own board.