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

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.

About

Mon, 01 Jan 0001 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. 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.

AltSql Ask Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

Each machine keeps a day of readings in its own AltSql database. You ask in SQL. The gateway turns the question into a small program, every machine answers from its own records, and only the answers travel back.

Simulated machines, real code. The machines, their readings and the network are simulated. AltSql Core and AltSql Ask run in this page, compiled to WebAssembly.

How to Run It

Ask the fleet. Pick a ready-made question or write your own SQL, choose the budget per machine, and press Ask the fleet. The page shows the program each machine receives, byte by byte, and what the question cost on the network.
Check the answer. The gateway pulls all 360,000 readings into one database and runs the same SQL there with AltSql Core. The two answers should be the same.
Try to break it. Squeeze the budget, ask for too many groups, or flip three bits of the program on its way to the machines. A question must never hang a machine, fill its memory or change its data.

On a wide screen the demo has more room: open it full screen.

AltSql Core Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

Three simulated devices run AltSql Core, the real Alpha engine, right here in your browser. Each one keeps its own records and decides for itself. Only what matters goes to its gateway, where the same records arrive byte for byte. The demo is open to everyone: there is no sign-up, nothing to install, and nothing you do here leaves this page.

Simulated devices, real Alpha engine. The sensors, networks and flash chips are simulated. The database is the Alpha engine itself, compiled to WebAssembly.

AltSql Core: The Alpha

Mon, 01 Jan 0001 00:00:00 +0000

The Alpha is the working prototype of AltSql Core, the base module the others are built around: one C file, its tests, a few tools and a demo that runs one engine on three simulated devices. It stores key-value pairs and time-series readings in flash on a microcontroller, answers SQL on a gateway, and copies records from device to gateway byte for byte.

Everything so far runs on a PC. The flash chips and radio links are simulated, carefully, but simulated. The code also compiles for four microcontroller families and its size was measured on each, but it has not yet run on any of them. That is the job of the Beta. The six prototypes built around Core have their own demos, listed on the modules page.

AltSql DB

Mon, 01 Jan 0001 00:00:00 +0000

AltSql DB is the next step of AltSql Core’s idea, taken to the gateway. Core keeps a device’s records in a log in its flash and copies them to the gateway byte for byte. AltSql DB gives a gateway that serves a whole fleet a database built for those records: every device in one file, values read and written by key without going through SQL, and SQL that uses the keys.

AltSql DB Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

Twelve devices run AltSql Core, each on its own flash chip, and every ten seconds each saves a reading and sends the gateway what it has not confirmed yet. The gateway keeps every device in one AltSql DB file, the devices’ bytes unchanged, and answers two ways: SQL, and a direct path with no SQL step at all.

Simulated devices and file, real code. AltSql Core and AltSql DB run in this page, compiled to WebAssembly. The chips and the gateway’s file are emulated in memory, so the power can be cut at any write.

AltSql Instant Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

A small solar cell charges a capacitor. When it is full, the sensor wakes, opens its store and saves readings, one after another, until the capacitor is empty and the power goes, wherever the sensor is at that moment: between readings, or in the middle of a write. Then it charges again, and wakes again, many times a minute. Two sensors, the same light, the same capacitor: one keeps its readings with AltSql Instant on MRAM, the other with AltSql Core on NOR flash.

AltSql Mesh Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

A sheep farm with no mobile coverage and no gateway. Three utes, four quad bikes and five people on foot carry a device each. They read the water troughs, open and close gates, add jobs and clear them, and count sheep, all into one shared table. Whenever two come within radio range they sync, over a link that loses messages. Stop the writing and watch every device end up with the same table.

AltSql Realtime Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

A controller runs a loop 100 times a second. Every cycle it writes one value, its state or, every tenth cycle, one of its settings, and logs a row, and those writes must be done within 10 ms of the cycle’s start. Its flash chip needs 45 ms to erase a sector, and up to 400 ms. AltSql Core erases inside the write that needs the room. AltSql Realtime never erases inside a write, and works out from its configuration the most any write can cost. It erases only when the loop calls idle: here, between cycles, while the chip erases in the background.

AltSql Vector Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

A vibration sensor sits on a motor. Every 1.6 seconds the device turns what it hears into a fingerprint, looks for the closest one it was taught, and names the state, or flags a pattern it does not know. You can teach it on the spot.

Simulated motor, real code. The motor, its faults and the sensor are simulated. AltSql Core and AltSql Vector run in this page, compiled to WebAssembly.

AltSql Wave Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

A vibration sensor on a pump’s motor keeps a 1.6-second burst four times a day, compressed without losing a bit, and sends only the burst’s features to the gateway. After three weeks a bearing starts to fail. Search the features with SQL, then fetch the raw signal behind any row.

Simulated motor, real code. The motor, the fault and the sensor are simulated. AltSql Core and AltSql Wave run in this page, compiled to WebAssembly.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

The project would like to hear from:

Device makers who would like a hardware pilot on one of their product lines.
Engineers with a chip, a flash part or an industry the project should test.
Anyone with a question about the modules, the demos or the figures on this site.

Write to info@altsql.com.

If you are writing about a device, it helps to mention its chip, how much flash and RAM it has, how it connects (Wi-Fi, cellular, LoRaWAN or something else), how often it measures, and what it should decide on its own.

Hardware Pilot

Mon, 01 Jan 0001 00:00:00 +0000

AltSql Core works in simulation. The proof that matters next is on real hardware, and the most useful hardware is a real product. A pilot fits AltSql Core to one of your product lines and runs it on your own board, against your own data.

Where things stand. The engine, its tests and its live demo run on a PC today. AltSql Core compiles for Arm Cortex-M0+, M4 and M33 and for RISC-V, but it has not run on a microcontroller yet. Its Beta puts it on real boards first, and pilots follow. Planning one can start now.

Live Demos

Mon, 01 Jan 0001 00:00:00 +0000

Eight live demos, one for each AltSql module built so far. Each runs the module’s own prototype code, compiled to WebAssembly, in your browser. The devices, their sensors and links, and their memory chips are simulated. Nothing needs installing, and nothing you do leaves the page.

Simulated devices, real code. Run without interference, each demo shows the figures its Alpha report gives for it. AltSql Vector’s differ a little in a browser, as its report explains.

Roadmap

Mon, 01 Jan 0001 00:00:00 +0000

AltSql Core goes first. Its Beta, about 16 weeks (estimate), takes the engine onto real chips, and a first release and a learned layer follow it. For now the project focuses on the engine and the database, both open source under the Apache License 2.0. AltSql DB, the database for the gateway built on Core, is at release 0.3.0-alpha, and its Beta comes next. The six prototypes built around Core wait meanwhile, each with a Beta plan of its own: five on the same boards, and AltSql Instant on boards with MRAM and FRAM. AltSql Private waits for an outside security review. Durations are estimates, and hardware surprises could stretch them.

Technical Brief

Mon, 01 Jan 0001 00:00:00 +0000

AltSql Core on one page, for engineers who want to judge whether it fits a device before asking for the full Alpha report. Every figure comes from the Alpha: measured on a PC, with the flash chips and links simulated, or computed where it says so. The engine compiles for four microcontroller families, and its size was measured on each, but it has not run on a microcontroller yet.

What It Is

One C file of 3,907 lines, in C99. A device gets a small build and a gateway gets a full one, and both keep the same records, byte for byte. The caller gives the engine one block of RAM at start-up, and the engine never calls malloc.

The Database

Mon, 01 Jan 0001 00:00:00 +0000

The database is the data the engine keeps: the records themselves, stored in order. In AltSql it’s one set of records from the sensor to the gateway, and both of the engine’s doors reach every one of them.

One Set of Records, From Sensor to Gateway

A device writes each reading or setting once, as a record with a sequence number and a checksum. The gateway receives those same records byte for byte and files each one under a key: for a reading, which device, what time and its sequence number. The payload stays exactly as the device wrote it. Nothing converts it on the way, so there’s no second copy to keep in step.

The Engine

Mon, 01 Jan 0001 00:00:00 +0000

The engine is the software: the code that writes records, finds them again, keeps them safe through a power cut and answers questions about them. AltSql’s engine is a native hybrid of key-value and SQL. It has two ways in, designed together, and both reach the same records.

Two Doors, Built Together

Get/put, the direct door. A read or write by key goes straight to the record: one walk down the store, with no SQL parser or planner in between. In the Alpha’s speed tests, reads by key never entered SQL code at all, checked under a debugger.
SQL, the asking door. SQL reads a question, plans it and turns it into walks and scans over the same records: a lookup by key, a range, a time range across a whole fleet, GROUP BY, UPDATE and DELETE.
One set of transactions. A put and a SQL statement can sit in the same transaction, so related changes are saved together or not at all.
The same rules. The same code checks types and keys whichever door a change comes through.

Small Enough for Both Ends

Where	What the engine does there	Size
On the device	The key-value door: readings and settings kept as records in flash, read back to decide on the spot, and sent on to the gateway as they are	About 15 KB of code as compiled for a Cortex-M4. The demo devices use 672 to 1,048 bytes of engine RAM, plus up to 1.4 KB of stack
On the gateway	Both doors, onto one store that holds a whole fleet	166,667 bytes of code at -O2 with both doors, about a sixth of SQLite’s 982,281 (computed from the measured sizes). It can open in 38 KB of memory, with small pages

It never calls malloc: the program hands it one block of memory when it starts. It’s written in C99, and a program links in one file per part.

The Modules

Mon, 01 Jan 0001 00:00:00 +0000

AltSql’s modules each take its native hybrid of key-value and SQL to one more job. AltSql Core is the base: the key-value door on the device and SQL on the gateway, with the same records on both. AltSql DB is the gateway’s database, with both doors onto one file for a whole fleet. Six more modules take the same idea to one problem each, in how devices keep, search and share their data. Everything so far runs on a PC: none of the modules has run on a microcontroller yet, and that is the job of the Betas, AltSql Core’s first.