Posts on AltSql.com

AltSql Is a Native Hybrid of Key-Value and SQL, From the Sensor to the Gateway

Fri, 02 Oct 2026 00:00:00 +0000

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. Everything else AltSql offers follows from that.

The engine is the software. The database is the data the software keeps. The engine is code: it writes records, finds them again, keeps them safe through a power cut and answers questions about them. The database is the records themselves, stored in order, usually in one file. In AltSql the hybrid lives in both. The engine is one piece of code with two ways in, and the database is one set of records that both ways reach.

AltSql Core and AltSql DB Are Now Open Source Under the Apache License 2.0

Mon, 05 Oct 2026 00:00:00 +0000

For now the project focuses on two products: the engine, AltSql Core, and the database, AltSql DB. Both are open source under the Apache License 2.0. The code is on GitHub. Premium add-ons may come later under different licenses.

AltSql keeps key-value and time-series records on the device and answers SQL on the gateway, with the same records on both, so nothing gets translated in between. The device keeps working and deciding when the link drops, and it sends less. The native hybrid post says why that matters.

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.

AltSql DB 0.3 Adds Secondary Indexes and Statement Savepoints: A Lookup on a Million Rows Ran 198 Times Faster Than a Full Scan

Mon, 05 Oct 2026 00:00:00 +0000

AltSql DB 0.3 adds the two things a gateway database needs once it holds real data. Tables get secondary indexes, so a question about a column other than the key no longer reads the whole table. And a statement that fails inside your transaction now fails on its own, while the transaction goes on.

Both come in the v0.3.0-alpha release on GitHub, open source under the Apache License 2.0. As with 0.2, every number here was measured in simulation on a PC. Nothing has run on a gateway yet.

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 DB 0.2: SQL and Direct Calls Wrote Byte-Identical Files Over 100,000 Random Steps

Mon, 05 Oct 2026 00:00:00 +0000

AltSql DB 0.2 makes the two ways into the database follow the same rules, and it makes sync cope with batches that arrive out of order. It also comes with a shell of its own.

It’s part of the v0.2.0-alpha release, which is open source under the Apache License 2.0. Every number below was measured in simulation on a PC, with the files held in memory and the link between devices and gateway simulated. Nothing has run on a gateway yet.

AltSql DB Keeps a Whole Fleet in One File and Reads by Key 5 Times Faster Than SQLite Through SQL

Fri, 02 Oct 2026 00:00:00 +0000

AltSql Core keeps a device’s readings and settings in its own flash and copies the same records to its gateway, byte for byte. A gateway that serves a whole fleet needs a database of its own, and AltSql DB is that database. When its design was written, this post set out what it would do and how it would be judged, before any numbers existed. The prototype, its live demo and its Alpha report are now done, and these are the numbers.

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.

AltSql Ask Puts One SQL Question to 500 Simulated Machines and Brings Back Only the Answers

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

An engineer wants to know which machines ran hot last night. The usual way is to pull every machine’s readings to a server first and ask there. That moves every raw reading, and on a slow or costly link the moving is the expensive part.

AltSql Ask turns that around. The gateway takes an ordinary SQL question and compiles it into a small program. It sends that program to every device. Each device runs it against its own records and sends back its share of the answer, and the gateway merges the shares into the rows the same SQL would have given over all the raw data.

Machine Monitoring Case Study: Overheat Alarm Handled on the Sensor While Wi-Fi Was Down

Mon, 28 Sep 2026 00:00:00 +0000

A temperature sensor on a machine takes one reading a second. When the machine runs hot, the fan has to come on right away, whether or not the plant’s Wi-Fi is working. In the Alpha demo this device runs the AltSql engine on 64 KB of flash with 1,048 bytes of engine RAM, and it makes that call by itself.

The run covers one simulated hour. Wi-Fi drops out from minute 20 to minute 35. Two gateways listen: gateway A receives every record, and gateway B, which stands in for a constrained link, receives only the minute summaries and the fan state.

Cold Chain Case Study: Truck Logger Records a 51-Minute Excursion With No Coverage

Sun, 27 Sep 2026 00:00:00 +0000

Medicines and fresh food travel in refrigerated trucks, and many loads must stay between 2 and 8 °C for the whole trip. When the cooling fails, somebody has to know how long the load was warm and how warm it got, even if the truck is nowhere near a mobile signal at the time. In the Alpha demo a logger inside the load keeps that record itself. It runs the AltSql engine on 512 KB of flash with 920 bytes of engine RAM.

Agriculture Case Study: Soil Sensor Runs the Valve Itself and Reports in 38 Bytes a Day

Sat, 26 Sep 2026 00:00:00 +0000

A soil sensor in a field usually runs on a battery and talks over a radio that carries a few dozen bytes a day. It cannot wait for a server to tell it when to water. In the Alpha demo the sensor decides for itself when to open the irrigation valve, and it reports to the farm office in one small radio message a day. It runs the AltSql engine on 32 KB of flash with 672 bytes of engine RAM.

AltSql Vector Teaches a Device What a Healthy Motor Sounds Like, in 32-Byte Fingerprints

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

A vibration sensor on a motor hears a lot. Most of it is the motor doing its job. The useful part is the moment the sound changes into something new, like a bearing starting to wear. Sending every sample to a server to find that moment costs bandwidth the device often does not have.

AltSql Vector lets the device do the listening. Every 1.6 seconds it splits what it hears into 32 frequency bands and turns that into a fingerprint of 256 bits, which is 32 bytes. It keeps fingerprints of the states it has been taught, such as idle, running and loaded. For each new fingerprint it finds the closest one it knows and names the state. When nothing it knows is close enough, it flags the pattern as one it was never taught.

AltSql Wave Keeps Raw Vibration Bursts on the Device, Lossless, and Sends Only Their Features

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

When a pump’s bearing starts to fail, an analyst wants two things. A quick figure to spot it, and the raw signal to understand it. Devices usually keep one or the other. They send summary figures and throw the signal away, or they send the signal and pay for every byte of it.

AltSql Wave keeps both. A sensor records a short burst of vibration, compresses it without losing a bit and stores it on the device, where the bursts stay for as long as its flash holds them. While the samples arrive, it works out the figures an analyst looks at first, such as RMS, peak and kurtosis, and the level in a few frequency bands. Only those figures go to the gateway, where SQL can search them. When a row looks interesting, the gateway fetches the raw burst behind it, checked against its CRC-32.

AltSql Mesh Keeps Twelve Devices on One Table on a Simulated Farm With No Signal and No Gateway

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

Some places have no mobile coverage and nowhere to put a gateway. A big sheep farm is one. The people working it still need the same picture: which troughs are low, which gates are open, what jobs are waiting and how many sheep are where.

AltSql Mesh gives every device its own copy of one shared table. Each device writes to its copy as its owner works. Whenever two devices come within radio range they bring each other up to date, over a link that may lose messages. No device is in charge and nothing waits for a server. Once every change has reached every device, all of them hold the same table, row for row, and any device with the memory for it can answer SQL about it.

AltSql Realtime Meets a 10 ms Deadline on a Simulated Flash Chip That Takes 45 ms to Erase

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

A controller runs its loop 100 times a second. Every cycle it saves a value and logs a row, and those writes have to finish within 10 ms. The trouble is the flash chip. Before it can reuse a sector it has to erase it, and on the chip the demo models, a Winbond W25Q32FV, an erase takes 45 ms typically and up to 400 ms at the slowest its datasheet allows. A storage engine that erases inside a write will, sooner or later, make the loop miss its deadline.

AltSql Instant: A Battery-Free Sensor on MRAM Saved 1,428 Readings in a Simulated Minute, Against 220 for AltSql Core on Flash

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

Some sensors have no battery. A small solar cell charges a capacitor, and when it is full the sensor wakes and works until the charge runs out. Then the power goes, wherever the sensor happens to be. It might be between readings or in the middle of writing one. Every bit of energy spent on storage is a reading not taken.

Flash memory makes this hard. It writes in pages and has to erase before it can write again, so a storage engine for flash keeps a log and cleans it up later. MRAM and FRAM work differently. They write single bytes, need no erase and keep what was written the moment the write ends.

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.