Electricity and power make up around 20% of global use, with manufacturing taking a portion of the pie closer to 30%. Migrating those systems is a very large hurdle, but I'll admit that whilst doing some investing around this recently, it seems to be a clear target by many organisations. Migrating traditional manufacturing processes for chemicals and base materials is going to have a massive impact on the overall situation.
In saying all this, the idea that we will be anything close to decarbonised by 2030 is a joke of epic proportions, the scale of the problem is mind boggling. Not that that means we shouldn't try, as it's a very necessary goal. But I actually think being more realistic about the scale of the issue is more likely to generate more interest in crafting fixes, as opposed to these bullshit goals that in many ways, make the problem sound solveable within the timeline. Which it isn't.
The bit that surprised me was that this thing supports writes as well!
It does it by acting as a PostgreSQL proxy. You connect to that proxy with a regular PostgreSQL client, then any read queries you issue run against the local SQLite copy and any writes are forwarded on to "real" PostgreSQL.
The downside is that now your SELECT statements all need to be in the subset of SQL that is supported by both SQLite and PostgreSQL. This can be pretty limiting, mainly because PostgreSQL SQL is a much, much richer dialect than SQLite.
Should work fine for basic SELECT queries though.
I'd find this project useful even without the PostgreSQL connection/write support though.
I worked with a very high-scale feature flag system a while ago - thousands of flag checks a second. This scaled using a local memcached cache of checks on each machine, despite the check logic itself consulting a MySQL database.
I had an idea to improve that system by running a local SQLite cache of the full flag logic on every frontend machine instead. That way flag checks could use full SQL logic, but would still run incredibly fast.
The challenge would be keeping that local SQLite database copy synced with the centralized source-of-truth database. A system like SQLedge could make short work of that problem.