About

AltSql is a native hybrid of key-value and SQL, in the engine and in the database: one small engine and one set of records, from the sensor to the gateway, with nothing to translate in between. The project is at an early stage. Its modules each take the hybrid to one job, from AltSql Core on the device to AltSql DB on the gateway, and each has a live demo that runs in your browser. Everything works in simulation so far, and the next step is 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

  • A native hybrid of key-value and SQL. One engine with two doors, get/put and SQL, designed together and working on one set of records under one set of rules. The native hybrid, the engine and the database
  • AltSql Core, the base module. Key-value, time-series, sync and SQL in one C file, with small builds for devices and a full build for gateways, and the same records on both. How it works and the technical brief
  • Six more modules. AltSql Ask, Vector, Wave, Mesh, Realtime and Instant each add one capability: questions to a whole fleet, vibration fingerprints, raw signal bursts, sync with no gateway, writes with a deadline, and storage for MRAM and FRAM. Each is one C file of 931 to 1,923 lines with its own tests and demo. Four keep their data in AltSql Core, Instant writes Core’s record format, and Realtime works with Core’s flash drivers. The modules
  • A database for the gateway. AltSql DB carries AltSql Core’s concept onto the gateway: a whole fleet’s records in one file, each stored byte for byte, read by key with no SQL step or with SQL that uses the keys. Its Alpha is done, with a live demo. AltSql DB
  • Proof on hardware. AltSql Core goes first: every chip family tested on real boards, with thousands of real power cuts per board, and the results published. The prototypes follow, five of them on the same boards and AltSql Instant on boards with MRAM and FRAM. 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. Despite its name, it does more than plan queries: most of its work is deciding what a device keeps, samples and sends.

An eighth module, AltSql Private, would give a gateway totals across devices without their individual readings. It is on hold until an outside security review.

How the Project Works

  • Measure, then say it. Every figure on this site was measured on the modules’ Alpha code, or is marked as computed or estimated. Each Alpha includes the commands that reproduce its numbers.
  • Say what is simulated. None of the modules has run on a microcontroller yet. The demos’ devices, sensors and links are simulated; the code in them is real.
  • Small by default. Features are compile-time switches, and code that is switched off is not compiled at all. AltSql Core 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

AltSql Core, the engine, and AltSql DB, the database, are open source under the Apache License 2.0. For now the project focuses on these two. The code is on GitHub, and the releases folder has Linux x86-64 binaries of their shells. The other modules are prototypes, all rights reserved, and the live demos are the way to see them run. Premium add-ons may come later under different licenses.

Questions People Ask

Can I download the engine?

Yes. The engine is open source under the Apache License 2.0, and its code is on GitHub, along with the database’s. The releases folder has Linux x86-64 binaries of the shells for both. It’s an alpha, so file formats may change. The live demo runs the AltSql Core Alpha itself, compiled for the browser, and the technical brief sums up what it supports.

Are the demos real?

The code is real: each module’s Alpha code, the same code measured in its tests, compiled to WebAssembly. The devices, their sensors, their radio links and their memory chips are simulated. The readings follow fixed scripts, so a run you leave alone ends with the figures in that module’s Alpha report. AltSql Vector’s differ a little in a browser, as its report explains.

How do the six prototypes relate to AltSql Core?

Ask, Vector, Wave and Mesh keep their data in AltSql Core and add their own layer on top. Instant is its own storage layer for MRAM and FRAM, and writes Core’s record format, so a gateway running Core takes its records as they are. Realtime is its own storage layer too, and works with the same flash drivers as Core. The modules page has the details.

Does it run on my microcontroller?

AltSql Core 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. Its Beta adds Xtensa (ESP32-S3) and tests all five families on real boards.

How much memory does it need?

For AltSql Core, about 7 KB of code for key-value only and about 15 KB for a sensor with time-series and sync, as compiled for 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 Core 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 AltSql Core’s 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

Can I try it on my own hardware?

That is what a hardware pilot is for: AltSql Core fitted to one of your product lines and run on your board. Pilots follow AltSql Core’s Beta, and planning one can start now.

Get in Touch

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