AltSql: Build IoT Products Without Depending on a Server
Bootstrapped founders building connected products face a hard choice: either the device depends on the server for everything, or you build a data converter that stays in sync forever. The device keeps readings and settings in its own format. The server wants those same values as database rows. Somebody writes a converter. Then somebody has to keep that converter alive, correct, and tested for ten years. Meanwhile, every format change on the device breaks things on the server, and every connection hiccup means retries and conflict resolution.
This is where IoT companies spend enormous amounts of engineer time without shipping new features. The product would work better if the device could make decisions locally, but the device depends on the server, so everything has latency. The server depends on the converter being right, so everything has risk.
AltSql takes the converter out. Its base engine is 15 KB of code that runs on a microcontroller. The device keeps its readings and settings in SQLite. The gateway keeps the same records, byte for byte, in SQLite. When the connection comes back after being down for days, sync is automatic and conflict-free.
For bootstrapped companies building IoT products, the payoff is radical: you don’t build a converter. The device and gateway speak the same language. You stay lean because you’re not hiring a specialist to keep sync logic alive.
A product feature like “the device switches the fan on if the last ten readings were all above 60 degrees Celsius” splits cleanly. The rule runs on the device in C, using a SELECT on the local database. No round trip to a server. No latency. The dashboard queries the same ten readings on the gateway. Both get their answer instantly. The device works when the connection drops. Rules fire immediately. Readings get stored locally. Settings apply locally. When the connection comes back, sync happens automatically.
The architecture is clean enough that a small team can maintain it. The device is independent; the gateway is independent; sync is conflict-free because both sides hold the same data in the same format. You’re not writing custom merge logic. You’re not engineering retries on top of retries. You’re writing SQL.
The business case is clear. You don’t hire a full-time engineer to keep a converter alive. You don’t debug sync conflicts at 3 AM. You don’t worry about what breaks when the network is down. You ship a product that works in the field, not just in the lab.
Six prototypes are built around Core, and the engines page lists them all. AltSql Ask puts one SQL question to a fleet of devices and brings back only the answers. AltSql Mesh lets devices share a table peer-to-peer with no gateway. The flexibility comes from having a real database on every device.
The project is at Alpha. So far everything has run on a PC with radio links simulated. Real hardware comes with the Beta. The live demos run the actual AltSql engine in your browser, compiled to WebAssembly.
Device makers who want to try it on real hardware can plan a pilot with the team.
For bootstrapped IoT companies, AltSql is the difference between hiring an engineer to maintain converter logic and shipping a product that works in the field. The device makes decisions locally. The gateway has the history for the dashboard. Sync is automatic. You stay lean because you eliminated the category of problem that would have required hiring someone. You built the product instead of the plumbing.
That’s how bootstrapped companies stay profitable building hardware: they use tools that eliminate entire classes of work instead of tools that automate existing work. AltSql lets you ship IoT products without depending on a server or hiring a specialist to keep sync logic alive.