Introduction

A connected product usually handles its data on two computers. The device is a microcontroller with kilobytes of RAM, flash that wears with every erase, and power that can vanish in the middle of a write. The gateway gathers data from many devices and passes it on. Each side has good tools of its own, and they don’t share a format. So every product team writes converter code between them, and somebody keeps it working for the ten or more years the device stays in service.

The bigger cost shows when the link drops. A device that cannot query its own data ships raw readings upstream and waits for another machine to decide. In the Alpha demo, the plant’s Wi-Fi was down when a machine ran hot, and its sensor raised the alarm and switched the fan on by itself. Deciding on the device saves traffic too: that sensor sent 2.5 KB in an hour over its constrained link, against 96 KB for every record and 191 KB as JSON.

AltSql is a native hybrid of key-value and SQL: one small engine for both sides, and one set of records. A sensor keeps its readings and settings in its own flash through the key-value door, reads them back to decide on the spot, and keeps working when the connection goes. Its gateway keeps the very same records, byte for byte, and answers questions about them in SQL. There is nothing to convert. The native hybrid and how it works

Modules Around It

AltSql Core is the base module. Six more take the same idea to one more problem each: Ask puts one SQL question to a whole fleet, Vector learns what a machine sounds like, Wave keeps raw vibration bursts searchable, Mesh shares a table with no gateway, Realtime bounds every write for a control loop, and Instant stores on MRAM and FRAM. Each is one C file with its own tests and live demo. The modules page says how each relates to Core, and AltSql DB is the gateway’s database.

What the Alpha Has Shown So Far

AltSql Core’s sensor build takes about 15 KB of code as compiled for a Cortex-M4, with key-value, time-series and sync. The three demo devices use 672 to 1,048 bytes of engine RAM, plus up to 1.4 KB of stack. In one test run the simulated power was cut 400,000 times, and after each cut everything reported as saved was still there. In the demo, the devices sent 26 to 76 times less data over their weak links than sending every record would take.

All of this was measured on a PC, with flash chips and radio links simulated. The engine compiles for four microcontroller families but has not run on one yet. That is what the Beta is for. The Alpha in detail and the technical brief

Where the Project Stands

AltSql Core’s Alpha is done: a working engine in one C file, tested hard in simulation, with a demo of three devices in three industries. Its Beta comes next: the same engine on real boards from five chip families, 10,000 real power cuts per board, and three devices running for a week. The six prototypes follow, five of them on the same boards, and v1.0 freezes Core’s on-flash format and API. See the roadmap

Try It, or Bring a Pilot

The live demo runs the real AltSql Core Alpha inside your browser. Three simulated devices go through an hour, two days and a month of readings in under a minute, each deciding for itself and syncing to its gateway. Pull the plug whenever you like: the device loses power in the middle of a write, reboots, checks every record it had saved and carries on. Open the live demo

Device makers who want to see AltSql Core on their own board, with their own data, can plan a hardware pilot.