litestream-base
chiselstore
| litestream-base | chiselstore | |
|---|---|---|
| 1 | 4 | |
| 32 | 563 | |
| - | 0.0% | |
| 0.0 | 0.0 | |
| about 2 years ago | over 1 year ago | |
| Dockerfile | Rust | |
| - | MIT License |
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.
litestream-base
-
Fly.io Buys Litestream
Litestream does a couple of things. It started as a way to continuously back sqlite files up to s3. Then Ben added read replicas – you can configure Litestream to replicate from a "primary" litestream server. It's still limited to a single writer, but there's no s3 in play. You get async replication to other VMs: https://github.com/fly-apps/litestream-base
We have a feature for redirecting HTTP requests that perform writes to a single VM. This makes Litestream + replicas workable for most fullstack apps: https://fly.io/blog/globally-distributed-postgres/
It's not a perfect setup, though. You have to take the writer down to do a deploy. The next big Litestream release should solve that, and is part of what's teased in the post.
chiselstore
-
SQLite: QEMU All over Again?
it? What's the big deal about not fitting well with SQLx? This isn't a requirement for such a library to be successful. What other problems is it allegedly suffering from?
[1] https://github.com/chiselstrike/chiselstore
- Fly.io Buys Litestream
-
Distributed SQLite for Rust
I've looked at the https://github.com/chiselstrike/chiselstore/blob/main/proto/... - and calling the service "RPC" is not great if this is going to be bundled with other gRPC services - why not call it "chiselStore" or something more concrete?
on a 2nd note, each method should have it's own Request Response, and ideally they should be suffixed same way. Returning same proto for multiple methods might break future compatibility - e.g. what if AppendEntries needs to return somehing else than Void? - ideally you make it from the start to return an empty AppendEntriesResponse, and then you can extend that proto.
https://developers.google.com/protocol-buffers/docs/proto3#u...
What are some alternatives?
Prisma - Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
rqlite - The lightweight, distributed relational database built on SQLite.
sqlite_fdw - SQLite Foreign Data Wrapper for PostgreSQL
better-sqlite3 - The fastest and simplest library for SQLite3 in Node.js.
risingwave - SQL stream processing, analytics, and management. PostgreSQL simplicity, unrivaled performance, and seamless elasticity. 🚀 10x more productive. 🚀 10x more cost-efficient.
dqlite - Embeddable, replicated and fault-tolerant SQL engine.
actordb - ActorDB distributed SQL database
exqlite - An SQLite3 driver for Elixir
honeysql - Turn Clojure data structures into SQL
incubator-horaedb - HoraeDB is a high-performance, distributed, cloud native time-series database.