absurder-sql
Posted by Standard-Ad9181@reddit | programming | View on Reddit | 15 comments
AbsurderSQL: Taking SQLite on the Web Even Further
What if SQLite on the web could be even more absurd?
A while back, James Long blew minds with absurd-sql — a crazy hack that made SQLite persist in the browser using IndexedDB as a virtual filesystem. It proved you could actually run real databases on the web.
But it came with a huge flaw: your data was stuck. Once it went into IndexedDB, there was no exporting, no importing, no backups—no way out.
So I built AbsurderSQL — a ground-up Rust + WebAssembly reimplementation that fixes that problem completely. It’s absurd-sql, but absurder.
Written in Rust, it uses a custom VFS that treats IndexedDB like a disk with 4KB blocks, intelligent caching, and optional observability. It runs both in-browser and natively. And your data? 100% portable.
Why I Built It
I was modernizing a legacy VBA app into a Next.js SPA with one constraint: no server-side persistence. It had to be fully offline. IndexedDB was the only option, but it’s anything but relational.
Then I found absurd-sql. It got me 80% there—but the last 20% involved painful lock-in and portability issues. That frustration led to this rewrite.
Your Data, Anywhere.
AbsurderSQL lets you export to and import from standard SQLite files, not proprietary blobs.
import init, { Database } from '@npiesco/absurder-sql';
await init();
const db = await Database.newDatabase('myapp.db');
await db.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)");
await db.execute("INSERT INTO users VALUES (1, 'Alice')");
// Export the real SQLite file
const bytes = await db.exportToFile();
That file works everywhere—CLI, Python, Rust, DB Browser, etc.
You can back it up, commit it, share it, or reimport it in any browser.
Dual-Mode Architecture
One codebase, two modes.
- Browser (WASM): IndexedDB-backed SQLite database with caching, tabs coordination, and export/import.
- Native (Rust): Same API, but uses the filesystem—handy for servers or CLI utilities.
Perfect for offline-first apps that occasionally sync to a backend.
Multi-Tab Coordination That Just Works
AbsurderSQL ships with built‑in leader election and write coordination:
- One leader tab handles writes
- Followers queue writes to the leader
- BroadcastChannel notifies all tabs of data changes No data races, no corruption.
Performance
IndexedDB is slow, sure—but caching, batching, and async Rust I/O make a huge difference:
Operation | absurd‑sql | AbsurderSQL |
---|---|---|
100k row read | \~2.5s | \~0.8s (cold) / \~0.05s (warm) |
10k row write | \~3.2s | \~0.6s |
Rust From Ground Up
absurd-sql patched C++/JS internals; AbsurderSQL is idiomatic Rust:
- Safe and fast async I/O (no Asyncify bloat)
- Full ACID transactions
- Block-level CRC checksums
- Optional Prometheus/OpenTelemetry support (\~660 KB gzipped WASM build)
What’s Next
- Mobile support (same Rust core compiled for iOS/Android)
- WASM Component Model integration
- Pluggable storage backends for future browser APIs
GitHub: npiesco/absurder-sql
License: AGPL‑3.0
James Long showed that SQLite in the browser was possible.
AbsurderSQL shows it can be production‑grade.
Joex3@reddit
Sqlite supports OPFS in the browser, which is way more suited for the job. So what's the point of this?
Standard-Ad9181@reddit (OP)
Very long answer here https://sqlite.org/forum/forumpost/9efecca1e1
tl;dr
OPFS with COOP/COEP headers is a non-starter for:
I do acknowledge there and here again that for apps that can use COOP/COEP, OPFS is clearly superior. For everyone else, this is the viable path.
Joex3@reddit
Thanks! Yeah I think compatibility might be the biggest reason then. Nice work!
beetroop_@reddit
Please, no, I'm so tired
Zomgnerfenigma@reddit
I don't know how rust is built, but I peeked into the code and was disappointed to find nothing sqlite like. But I figured out that it imports sqlite-wasm-rs, which seems to be the actual sqlite port. Just saying that there is some potential misunderstanding what it does or is.
Standard-Ad9181@reddit (OP)
"Reimplementation" = the VFS/storage layer, not SQLite itself.
That would be pointless. sqlite-wasm-rs provides SQLite bindings (standard approach). The actual work is the custom VFS intercepting file I/O and translating to IndexedDB blocks with multi-tab coordination, export/import, etc.
Zomgnerfenigma@reddit
thanks for the clarification!
Standard-Ad9181@reddit (OP)
of course!
Standard-Ad9181@reddit (OP)
"Reimplementation" = the VFS/storage layer, not SQLite itself. That would be pointless. sqlite-wasm-rs provides SQLite bindings (standard approach). The actual work is the custom VFS intercepting file I/O and translating to IndexedDB blocks with multi-tab coordination, export/import, etc.
paul_h@reddit
All the features of sqlite3 but in the dom too?
Standard-Ad9181@reddit (OP)
I dive a lot deeper here https://sqlite.org/forum/forumpost/c9d93da925 but short answer,
Yes.
Full SQLite functionality via sqlite-wasm-rs with a custom VFS that redirects file I/O to IndexedDB.
All SQL features work:
- transactions
- indexes
- triggers
- views
- CTEs
- etc.
Only constraint is storage backend (IndexedDB instead of filesystem), but SQL layer is complete SQLite. :)
paul_h@reddit
Seems to me feature parity for sqlite3 should be higher up in the pitch. Next question: what is your $fee model?
Standard-Ad9181@reddit (OP)
make cool stuff and let me know what you make so I can add it to the github and bring more awareness to it. all OSS so have fun, freely!
paul_h@reddit
You picked AGPL. Companies wanting to use your tech will not want to make derived software available for download from the webapp in question, so they will want to know your dollar-paying licensing terms.
Standard-Ad9181@reddit (OP)
AGPL-3.0 is intentional. If you use AbsurderSQL in a closed-source webapp, you must make your derived code available to users.
For commercial/proprietary use without AGPL restrictions, contact me about dual licensing. I'm open to commercial arrangements, just haven't formalized pricing yet since this just launched.
The npm package and codebase remain AGPL-3.0 for open source use.