Roadmap
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.
The picture shows AltSql Core and the learned layer. The six prototypes are further down.
| Stage | Status | What it covers |
|---|---|---|
| AltSql Core’s Alpha | Done | A working engine, tested hard in simulation |
| The six prototypes’ Alphas | Done | Six modules around Core, each with its tests and a live demo, in simulation |
| AltSql Core’s Beta | Next, about 16 weeks (estimate) | Five chip families, real power cuts, three devices on real hardware for a week |
| The prototypes’ Betas | After Core’s Beta | Core’s boards for five, boards with MRAM and FRAM for Instant, each with its own plan |
| AltSql DB | Alpha done, with a live demo | A database for the gateway: a whole fleet in one file, a direct path by key, SQL that uses the keys |
| Advanced Beta | Later | The Learned Query Optimizer, in four phases |
| v1.0 | Planned | AltSql Core’s first release, with the format and API frozen |
| AltSql Private | On hold | An outside security review first |
AltSql Core’s Beta: Real Chips
This Beta is AltSql Core’s, and the 16 weeks below are its own. It has two goals. The first is the same engine, unchanged, running and tested on real boards from five microcontroller families, with every number from the Alpha measured again on the chips themselves. The five are the four already compiled for the Alpha plus Xtensa, the ESP32 cores that the Alpha’s compiler could not target.
| Chip family | Board | Price | Why this board |
|---|---|---|---|
| Arm Cortex-M0+ | Raspberry Pi Pico (RP2040) | $4 | The smallest target. Data shares the flash chip with the program |
| Arm Cortex-M4 | ST NUCLEO-WL55JC1 (STM32WL55) | $46.95 | Internal flash written 8 bytes at a time, and a built-in LoRa radio for the soil sensor |
| Arm Cortex-M33 and RISC-V | Raspberry Pi Pico 2 (RP2350) | $5 | One chip that runs either Arm or RISC-V cores: two instruction sets on one board |
| RISC-V | Espressif ESP32-C6-DevKitC-1 | $9.95 | Wi-Fi 6 and Bluetooth, with flash partitions managed by ESP-IDF. The machine sensor |
| Xtensa | Espressif ESP32-S3-DevKitC-1 | $19.95 | The ESP32 family with Xtensa cores and optional flash encryption. The cold-chain logger |
Prices as listed by the maker or a retailer in September 2026.
Work Packages
- Flash drivers. One small driver per family (read, write, erase), built on the vendor’s own flash functions: the Pico SDK, the STM32 libraries and ESP-IDF partitions. They plug into the same four-function interface the Alpha already uses.
- Tests on the chips. The existing test suites, trimmed to fit, run on every board. They also run in emulators (QEMU for Arm Cortex-M and RISC-V) on every change to the code.
- A power-cut rig. A relay or transistor switch, driven by a spare Pico, cuts each board’s power at random moments while it writes. The target is 10,000 real cuts per board, checked against the same model as in the simulation.
- Measurements. Whole-firmware size, RAM and stack, time per operation, flash wear, and energy per reading with a power profiler.
- Engine changes the chips ask for. A faster checksum (a table, or the chip’s hardware CRC unit), an optional single-precision build, locking hooks for firmware with threads, and whatever else the hardware turns up.
The Demo, for Real
The second goal is the demo on real hardware. Three devices, one per industry, each on a different chip family, with real sensors and radios, all report to one gateway and run for a week.
| Industrial machine monitoring | Cold chain and logistics | Agriculture | |
|---|---|---|---|
| Board | ESP32-C6 (RISC-V) | ESP32-S3 (Xtensa) | NUCLEO-WL55JC1 (Arm Cortex-M4) |
| Sensors and outputs | A temperature probe on a motor or heater; a relay for the fan | A temperature probe and a door switch in a cool box | A capacitive soil-moisture probe; a relay standing in for the valve |
| Link | Wi-Fi to the gateway | Wi-Fi only in “depot” windows; the full read-out at the “dock” | LoRaWAN (EU868), one message a day of at most 51 bytes, through The Things Indoor Gateway ($79) |
| Rule on the device | Overheat alarm and fan | Excursion record | Irrigation valve |
The gateway is a Linux machine, a Raspberry Pi or a PC, running the full build with SQL over all three. A cool box stands in for the truck, and a Wi-Fi access point switched on and off stands in for mobile coverage. A cellular modem can replace it later without touching the engine.
From a Set-Up File to a Build
In the Alpha each device’s set-up is written by hand in the demo’s C code. In the Beta each device gets a short set-up file: flash area and sector size, write alignment, memory, series layouts, the parameters of the rule on the device, what to send, and how large a message may be. A small generator turns the file into build settings and start-up code for that device. Success is measured in time: a new sensor, or a new industry, set up and running on a board in days.
Timeline: About 16 Weeks
| Weeks | Work |
|---|---|
| 1 to 3 | Drivers for the Pico and the ESP32-C6. Emulator tests on every change. Whole-firmware size measured |
| 4 to 7 | The Pico 2 (Arm and RISC-V), the STM32WL and the ESP32-S3. The power-cut rig: 10,000 cuts per board. Timing and energy measured |
| 8 to 11 | The three industry devices with sensors and radios. The set-up generator. The gateway |
| 12 to 14 | The 7-day run of all three devices, and the fixes it calls for |
| 15 to 16 | Beta release: the on-flash format and API frozen for Beta users, documentation, and a Beta report with every figure measured again |
The Beta needs two to three people: a lead engineer who also writes the drivers, one embedded engineer full time, and part-time help with the test rig and the tools. Hardware costs little. Two of each board, the sensors, the LoRaWAN gateway, a power profiler and the power-cut rig come to well under $1,000.
When the Beta Is Done
- The engine’s test suites pass on all five chip families, on the boards and in emulators.
- At least 10,000 real power cuts per board, with no acknowledged write lost and no database that fails to open.
- Whole-firmware size, RAM, stack, time per operation and energy per reading measured on every board and published.
- The engine’s own code size on each board within 10% of the Alpha’s figures.
- The three industry devices run for 7 days, each deciding by itself and syncing to one gateway, with no data lost.
- Each device built from its set-up file, with the time to set up a new one recorded.
- Coverage-guided fuzzing runs every night with no open crash.
Out of scope for the Beta: a graphical set-up tool, a cloud service, certification and new SQL features. Sync security gets a design during the Beta and code after it.
After Core’s Beta: The Six Prototypes
Five of the six run their Betas on the same boards as AltSql Core’s, and AltSql Instant needs boards with MRAM and FRAM. Each prototype’s Alpha report sets out its plan in full. In short:
| Module | Its Beta | Done when |
|---|---|---|
| AltSql Ask | The runner on the five chip families; programs signed by the gateway; long questions run in slices; standing questions; answers carried over Core’s sync and MQTT | A device refuses every program its gateway did not sign, and the same questions give the same answers on real boards |
| AltSql Vector | A real accelerometer on the Beta boards; fingerprints that follow the running speed; an index for large libraries; a field pilot on real pumps, fans and motors | False alarms and faults caught are measured on real machines, against a vibration analyst |
| AltSql Wave | A real accelerometer; a setting for small chips; envelope features for bearings; features kept apart from samples; a field pilot | Every round trip is lossless on every board, and feature trends are measured on real machines |
| AltSql Mesh | Real radios, Bluetooth Low Energy and sub-GHz; every message authenticated, then encrypted; retiring devices; radio frames as small as 50 bytes; a site with no network, for weeks | Fleets converge over real radios, and messages from outside the fleet are refused |
| AltSql Realtime | A flash driver for the W25Q32 family that erases in the background; a faster start; a real control loop on a test bench or a production line | A loop writing every 10 ms on a real chip misses no deadline over a week |
| AltSql Instant | Boards with MRAM and with FRAM; a rig that cuts the power at chosen moments of a write; a sensor with no battery, running for weeks | A battery-free sensor on a real board keeps every acknowledged reading through a week of power cuts |
None of the six has a duration yet. Each starts once AltSql Core’s Beta has put the engine on real boards.
AltSql DB: Alpha Done
AltSql DB runs on gateways, so its work doesn’t wait for the microcontroller boards of AltSql Core’s Beta. Its path, in order:
| Step | What it covers |
|---|---|
| Design | Done on 2 October 2026: the storage, the keys, sync into the tree, the direct path and the SQL |
| Prototype and demo | Done on 2 October 2026: keyed reads 5 times as fast as SQLite through SQL, the file at a commit after every one of 3,354 power cuts, and a live demo |
| Alpha | Done on 2 October 2026: the same answers as SQLite on 75,093 random queries, AltSql Core’s one-million-row benchmark faster than Core’s gateway copy on all five of its queries |
| Release 0.2.0-alpha | Done on 5 October 2026: one write path for every way of changing a row, and sync that applies batches in order, with the altsql-db shell alongside |
| Release 0.3.0-alpha | Done on 5 October 2026: secondary indexes, kept up to date by every way of changing a row, and statement savepoints, so a statement that fails inside a transaction no longer spoils it |
| Beta | Next: on a Linux gateway such as a Raspberry Pi, with devices running AltSql Core reporting to it for weeks; one sync per commit; the speed tests on a quiet machine |
The Beta has no duration yet. About AltSql DB
AltSql Core Toward v1.0
AltSql Core’s first production release should follow about 6 to 9 months after its Beta (estimate). Most of the work is what turns a tested engine into something a product can depend on:
- Secure sync. Authentication and encryption, so a gateway accepts records only from its own devices.
- One position per gateway. Today a device remembers only the most advanced gateway’s position, so with several gateways a lagging one can miss a delete. Each gateway gets its own.
- Firmware with threads. Locking hooks for devices where several tasks use the database.
- More chips and flash parts, with drivers proven on the power-cut rig.
- Documentation and tooling. A full API reference, a written sync protocol specification, and automatic testing on every change.
- Pilots in the field, on devices that belong to someone else.
- A frozen format. From v1.0 on, the on-flash format and the API stay stable, so records written by one version stay readable by the next.
Advanced Beta: The Learned Query Optimizer
After AltSql Core’s Beta comes an optional learned layer, the Learned Query Optimizer. 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. It lets the engine take its situation into account (battery, link, storage, events and the data itself) when it decides what to keep, what to send and how to answer. The gateway learns, each device decides, and the application sets the limits. It comes in four phases, and the work can stop after any of them:
| Phase | What it adds | Duration (estimate) |
|---|---|---|
| 1. Foundations | Summaries in their own storage area; statistics kept while writing; exact answers from summaries; sync from gateway to device | 2 to 3 months |
| 2. Gateway learning | Models trained on the gateway and pushed to devices as records; approximate SQL answers with declared error bounds | 3 to 4 months |
| 3. Device adaptation | Contracts in the set-up file; adaptive retention and sampling; learned alerts under hard limits; tests on the three Beta devices | 4 to 6 months |
| 4. Fleet learning | Models learned across many devices; ready model packs per industry | Ongoing |
The first phase changes storage and sync, so it is planned to land before the v1.0 format freeze. The layer is designed to add no code at all when it is compiled out.
AltSql Private
AltSql Private, for totals across devices without their individual readings, is on hold. It should not protect real data before people outside the team have reviewed its code and protocol, so an outside security review comes first.
Later: More Industries
The three demo industries share a pattern: a device that keeps data, decides for itself and talks over a limited link. The same pattern shows up in energy metering, smart buildings, water networks, retail refrigeration, vehicle fleets, drones, healthcare devices and consumer electronics. None of them is tested yet. The post on next verticals looks at what each would need.
Open Questions
- The license. Decided. AltSql Core and AltSql DB are open source under the Apache License 2.0, on GitHub. Premium add-ons may come later under different licenses.
- Pilots. AltSql Core’s Beta devices are built by the project itself. Pilots on other people’s devices come after it, and planning one can start now: see the pilot page.