Roadmap on AltSql.com

Introduction

Fri, 25 Sep 2026 00:00:00 +0000

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.

How It Works

Fri, 25 Sep 2026 00:00:00 +0000

The idea. A native hybrid of key-value and SQL: a very small database on the device that reads the sensors, keeping its data so that the gateway’s database can use it as it is, byte for byte, with no translation step.

The Whole Chain at a Glance

From the sensor to the cloud: where each part sits, and which way the data moves.

AltSql Core and Six Prototypes Built Around It

Thu, 01 Oct 2026 00:00:00 +0000

AltSql Core is the base module, the one the project started with. It keeps key-value data and time-series readings on a device, answers SQL on a gateway, and copies the same records to both, byte for byte. It is the foundation, and it goes onto real chips first.

Around it now sit six prototypes. Each takes Core’s idea to one more problem in how devices keep, search and share their data. Each is small: one C file of 931 to 1,923 lines, with its own tests, measured results and a live demo on the live demo page.

The Learned Query Optimizer

Fri, 25 Sep 2026 00:00:00 +0000

Status: planned for the Advanced Beta.

The Alpha answers every query the same way, whatever state the device is in. A device in the field is rarely in the same state twice: its battery runs down, its link comes and goes, its flash fills and wears, and its data turns from routine to alarming. The Learned Query Optimizer (LQO) is a planned, optional layer that lets AltSql take its situation into account. Despite its name, it does more than plan queries: most of its work is deciding what a device keeps, samples and sends, and where an answer comes from.

Next Verticals: Eight Industries Where a Database on the Sensor Could Fit

Fri, 25 Sep 2026 00:00:00 +0000

The three case studies share one pattern. A device keeps its own data, decides for itself and talks over a link that is slow, costly or often down. Its gateway receives the same records the device wrote, so nobody has to maintain code that translates between the two. Machine monitoring, cold chain and agriculture came first because the Alpha demo covers them.

The pattern turns up in many more industries. None of the eight below has been tested, and none has a device in the Beta. This post sets out what each would ask of the engine, what already carries over from the demo, and what would be new work. It is a map for choosing what to try after the Beta, ideally together with people who build these devices.