stolon VS absurd-sql

Compare stolon vs absurd-sql and see what are their differences.

Our great sponsors
  • SonarQube - Static code analysis for 29 languages.
  • Scout APM - Less time debugging, more time building
  • SaaSHub - Software Alternatives and Reviews
stolon absurd-sql
4 9
3,650 3,295
1.4% -
2.5 6.2
6 days ago 7 months ago
Go JavaScript
Apache License 2.0 MIT License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of stolon. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-09-30.


Posts with mentions or reviews of absurd-sql. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-17.
  • Extending SQLite with Rust
    4 projects | | 17 May 2022
    Have you looked into absurd-sql? it does exactly that:
  • Looking for help hosting
    3 projects | | 5 Mar 2022
    Maybe you could do something like this and search on an index. You could generate the DB and host it as static files.
  • Consider SQLite
    13 projects | | 29 Dec 2021
    I believe SQLite is about to explode in usage into areas it’s not be used before.

    SQL.js[0] and the incredible “Absurd SQL”[1] are making it possible to build PWAs and hybrid mobile apps with a local SQL db.

    Also I recently discovered the Session Extension[2] which would potentially enable offline distributed updates with eventual consistency!

    I can imagine building a SAAS app where each customer has a “workspace” each as a single SQLite db, and a hybrid/PWA app which either uses a local copy of the SQLite db synced with the session extension or uses a serveless backend (like CloudFlare workers) where a lightweight function performs the db operations. I haven’t yet found a nice way to run SQLite on CloudFlare workers, it need some sort of block storage, but it can’t be far off.




  • CPython's main branch running in the browser with WebAssembly
    9 projects | | 28 Nov 2021
    I know Absurd SQL[0] uses SharedArrayBuffer and Atomics to turn the async IndexDB into sync for use by Wasm. I wander if it’s possible to use that here too although it’s obviously a little different?




  • Why IndexedDB is slow and what to use instead
    4 projects | | 23 Nov 2021
    This mentions Absurd-SQL[0] which I only discovered recently. It’s seriously clever, worth reading the blog post[1] to see how it works!

    I think there is a good chance Absurd-SQL will get folded into SQLite.js.



  • Downsides of Offline First
    7 projects | | 1 Oct 2021
    It's infuriating to me that WebSQL was killed. 99% of real-world data is relational and yet the powers that be decided that we should all be forced to use IndexedDB and hacky layers like PouchDB built atop it.

    I'm exciting about though.

  • Ask HN: What could a modern database do that PostgreSQL and MySQL can't
    16 projects | | 5 Sep 2021
    absurd-sql[1] is the coolest thing I've seen in this space so far. sqlite.js brings sqlite to the browser via wasm, and then absurd-sql implements the storage layer in IndexedDb. So now we have an sqlite compatible db in the browser to play with.

    There is also alasql[3] which is implemented in js, and lovefield[2] from Google which seems like an experiment that is now abandoned.

    First, you could implement a REST/GraphQL cache in SQL. This would require maintaining mappings of your API response fields to SQL tables.

    Going further, you could implement your backend API on the client, and have requests to it go directly to your browser SQL db. The benefit of this is you write your API once, and you get full offline support. If you don't need "local-first" then it's just a matter of figuring out when a query becomes invalid on the server. I could show instant results from local db, and then send a query to the server to ask if the data I already have in my cache can fulfill this request. Could optimize this on the server by listening to DML queries via WAL/LISTEN. WebSockets would be used to maintain real-time updates to only the data you are viewing.

    You could also just use SQL directly as your UI API and then trigger these queries on the backend (respecting security of course).

    What's doesn't feel optimal though is subscribing to sqlite.js updates in the browser. This makes me feel like we need an SQL db written in JS.

    Also, if our DB is running in the same execution environment as our frontend and has one consumer, we could store each row as a JS object, and then reference this directly in our views, and subscribe to updates on a row-by-row basis. So if you are rendering a large table, if a column in a single row changes, when this row is updated in the database, instead of re-rendering the entire table manually, (or smartly detecting if the query was invalidated), you just bind to updates on the row instance, which is what the db is actually storing. I think this would reduce huge amounts of code.

    Local-first is a little more difficult. There is some good exploration here[4].

    I think writing a db in JS on the backend is not such a bad idea either. The hot paths would be written as Rust addons, but the majority of stuff people want today is just implementing the right logic to automatically handle denormalizations and subscriptions which we already hack together in our application layer using JS et al.


  • I am building an alternative to Roam Research for six months now
    1 project | | 26 Aug 2021
    Instant startup time — no matter how extensive your database is (with the help of SQLite + )
  • absurd-sql: sqlite3 in ur indexeddb (hopefully a better backend soon)
    1 project | | 12 Aug 2021

What are some alternatives?

When comparing stolon and absurd-sql you can also consider the following projects:

patroni - A template for PostgreSQL High Availability with Etcd, Consul, ZooKeeper, or Kubernetes

lovefield - Lovefield is a relational database for web apps. Written in JavaScript, works cross-browser. Provides SQL-like APIs that are fast, safe, and easy to use.

dolt - Dolt – It's Git for Data

crdt-example-app - A full implementation of CRDTs using hybrid logical clocks and a demo app that uses it

realtime - Listen to your to PostgreSQL database in realtime via websockets. Built with Elixir.

postgres - 🐘 Run PostgreSQL in Kubernetes

citus - Distributed PostgreSQL as an extension

localForage - 💾 Offline storage, improved. Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API.

donutdb - Store and query a sqlite db directly backed by DynamoDB.

meteor-mysql - Reactive MySQL for Meteor

yugabyte-db - The high-performance distributed SQL database for global, internet-scale apps.

remco - remco is a lightweight configuration management tool