verneuil
mvsqlite
Our great sponsors
verneuil | mvsqlite | |
---|---|---|
5 | 26 | |
388 | 1,295 | |
1.8% | - | |
6.7 | 0.0 | |
about 1 month ago | 3 days ago | |
C | Rust | |
MIT License | Apache License 2.0 |
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.
verneuil
- Show HN: Query SQLite files stored in S3
- LiteFS a FUSE-based file system for replicating SQLite
-
Ask HN: P2P Databases?
https://github.com/backtrace-labs/verneuil/ is one way to address the diffing / read replica part of the problem. I believe it's compatible with gossipping: most of the data is in small content-addressed chunks, with small manifests that tell clients what chunks to fetch and how to reassemble them to recreate a sqlite database. There's already client-side caching to persistent storage, and chunks can be fetched on demand.
Sharing replication data P2P, while retaining the simplicity of a single authoritative writer per database, is explicitly part of the project's long-term goals!
mvsqlite
-
FoundationDB: A Distributed Key-Value Store
I’ve been using FDB for toy projects for a while. It’s truly rock solid. That being said, I wish there were more layers.
Ideally someone could implement the firestore or dynamodb api on top.
-
Go bindings to SQLite using Wazero
For the rough plan, it's Cloud Backed SQLite meets FoundationDB.
-
SQLite-based databases on the Postgres protocol? Yes we can
- Oh, and if you're wondering about backup to S3, they have that too: https://github.com/libsql/bottomless
- Uh, sqld can integrated with this https://github.com/losfair/mvsqlite, so now your SQLite is backed by FoundationDB!?
- Meanwhile Litestream exists https://github.com/benbjohnson/litestream/
-
We Built Fly Postgres
This was on HN a few months back: https://github.com/losfair/mvsqlite
While not Spanner, it is essentially an open source db like AlloyDB or Aurora, pushing replication and scale out to the storage layer (in this case via FoundationDB). The most interesting bit of mvsqlite is it's multi-writer capabilities, using FoundationDB to perform page-level locks.
I'm neither the creator nor using it in production, but I'd love to see more DBs using FoundationDB as storage. It's a pretty cool solution.
-
Litestream doesn't do SQLite replication anymore (LiteFS does)
Shameless plug of my [mvSQLite](https://github.com/losfair/mvsqlite) project here! It's basically another distributed SQLite, but with support for everything expected from a proper distributed database: synchronous replication, strictly serializable transactions, + scalable reads and writes w/ multiple concurrent writers.
-
SQLite: QEMU All over Again?
The approach to edge-ifying SQLite taken in [1] looks quite promising - using FoundationDb as the storage handles a lot of hairiness.
This project looks really exciting!
I'm working on mvsqlite [1], a distributed SQLite based on FoundationDB. When doing the VFS integration I have always wanted to patch SQLite itself, but didn't because of uncertainty around correctness of the patched version...
A few features on my wishlist:
1. Asynchronous I/O. mvsqlite is currently doing its own prefetch prediction that is not very accurate. I assume higher layers in SQLite have more information that can help with better prediction.
2. Custom page allocator. SQLite internally uses a linked list to manage database pages - this causes contention on any two transactions that both allocate or free pages.
3. Random ROWID, without the `max(int64)` row trick. Sequentially increasing ROWIDs is a primary source of contention, and causes significant INSERT slowdown in my benchmark [2].
-
Show HN: Query SQLite files stored in S3
That DynamoDB VFS looks cool! I agree that the VFS api makes one think about plenty of crazy ideas. Someone is working on a VFS based on Foundation DB[0] that looks very promising. It was recently discussed here[1]
-
Turning SQLite into a Distributed Database
Hi mrkurt!
Litestream/LiteFS are amazing projects. The FUSE-based approach is interesting (I'm implementing something similar in mvSQLite, thanks for the idea!)
> Graceful failure
mvSQLite is designed to continue to operate under degraded network (there is a fault-injection test specifically for checking this property: https://github.com/losfair/mvsqlite/blob/1dd1a80d2ff7263b07a...). Network errors and service unavailability are handled with idempotent retries and not exposed to the application.
> Good for caching
mvSQLite caches pages read and written, and does differential cache invalidation (only remotely modified pages are invalidated in the local page cache). The local cache is just a regular KV store with invalidation strategies, and can be moved onto the disk. So it essentially becomes a consistent local database snapshot.
What are some alternatives?
dqlite - Embeddable, replicated and fault-tolerant SQL engine.
awesome-sqlite - A curated list of awesome things related to SQLite
litefs - FUSE-based file system for replicating SQLite databases across a cluster of machines
rqlite - The lightweight, distributed relational database built on SQLite.
datasette-stripe - A web SQL interface to your Stripe account using Datasette.
blueboat - All-in-one, multi-tenant serverless JavaScript runtime.
go-ds-crdt - A distributed go-datastore implementation using Merkle-CRDTs.
fdb-document-layer - A document data model on FoundationDB, implementing MongoDB® wire protocol
litestream - Streaming replication for SQLite.
sqlitedao - Simple dao for sqlite for personal/desktop projects
WCDB - WCDB is a cross-platform database framework developed by WeChat.