About

AltSql is a project at an early stage. Its engine works in simulation, a live demo runs it in your browser, and the next step is to prove it on real chips. This site shows where the project stands, gaps included.

Why the Project Exists

A connected product usually has two computers that handle its data. One is the device: a microcontroller with kilobytes of RAM and flash memory that wears with every erase, where power can vanish mid-write. The other is a gateway that gathers data from many devices and passes it on, often to a cloud.

Each side has good tools of its own. Small key-value stores fit the device, and SQLite fits the gateway. They don’t share a format, so every product team writes glue code that converts the device’s data for the gateway’s database, and somebody maintains it for the life of the product. Glue is where format drift and quiet data bugs live.

The gap costs more than engineering time. A device that cannot query its own data ships raw readings upstream and waits for another machine to decide. That wastes bandwidth and leaves the device stuck when the link drops. In the Alpha demo, a machine sensor that decided for itself sent 2.5 KB in an hour over its constrained link, against 96 KB for every record and 191 KB as JSON.

What the Project Is Building

  • The engine. Key-value, time-series, sync and SQL in one C file, with small builds for devices and a full build for gateways. How it works
  • Proof on hardware. Every chip family tested on real boards, with thousands of real power cuts per board, and the results published. The roadmap
  • A faster way to fit each device. A short set-up file describes the chip, flash, memory, data, rules and link, and a generator turns it into a build.
  • Later, a learned layer. The Learned Query Optimizer lets each device adapt what it keeps and sends, within limits the application sets.

How the Project Works

  • Measure, then say it. Every figure on this site was measured on the Alpha code, or is marked as computed or estimated. The Alpha package includes the commands that reproduce each number.
  • Say what is simulated. The Alpha has not run on a microcontroller yet. The demo’s devices, sensors and links are simulated; the engine is real.
  • Small by default. Features are compile-time switches, and code that is switched off is not compiled at all. The engine never allocates memory after start-up.
  • One format from sensor to gateway. Records are defined byte by byte, so they are identical on every chip.

License and Availability

The engine is not public yet. The license will be chosen before the first public release. The plan is a proprietary engine, with an open-source branch under consideration. Until then the prototype is marked “all rights reserved”, and the live demo is the way to see it run.

Questions People Ask

Can I download the engine?

Not yet. It will be available once the license is chosen, around the first public release. The live demo runs the Alpha engine itself, compiled for the browser.

Is the demo real?

The database engine is real: the Alpha, the same code measured on the Alpha page, compiled to WebAssembly. The devices, their sensors, their radio links and their flash chips are simulated. The readings follow a fixed script, so a run without power cuts ends with exactly the Alpha’s published numbers.

Does it run on my microcontroller?

It compiles for Arm Cortex-M0+, M4 and M33 and for RISC-V, and its code size was measured on each. It has not run on a chip yet. The Beta adds Xtensa (ESP32-S3) and tests all five families on real boards.

How much memory does it need?

About 7 KB of code for key-value only and about 15 KB for a sensor with time-series and sync, on a Cortex-M4. Engine RAM on the three demo devices is 672 to 1,048 bytes, plus up to 1.4 KB of stack. A sensor should budget about 2.5 KB of RAM for the engine.

How is it different from SQLite?

SQLite is far more capable and far more tested. It is also too large for most microcontrollers. AltSql puts a small build on the device and a full build on the gateway, with the same records on both and sync built in. On a PC, AltSql was faster than SQLite at grouping over time-ordered data and slower at filters and sorts that touch every row.

What happens when the flash fills up?

The oldest time-series rows roll over first, and settings are kept. In the demo the soil sensor’s 32 KB held almost a week of readings at a time. By the end of the month it had rolled over 2,228 older readings and 23 daily summaries, and every one of those summaries was already safe at the farm office.

Is sync secure?

Not yet. In the Alpha a gateway trusts any correctly formed record. Authentication and encryption get a design during the Beta and code after it.

What is the Learned Query Optimizer?

A planned layer for after the Beta. The gateway learns from the data and situation of many devices, and small models on each device adjust what it keeps, what it sends and how it answers, within rules the application sets. Records that must stay exact, such as a cold-chain log, stay exact. More about it

Get in Touch

Device makers who would like to try the Beta on their own hardware, and anyone with a question or an industry the project should look at, are welcome to write.