mvsqlite
fdb-document-layer
Our great sponsors
mvsqlite | fdb-document-layer | |
---|---|---|
26 | 5 | |
1,315 | 204 | |
- | 0.5% | |
0.0 | 0.0 | |
6 days ago | almost 3 years ago | |
Rust | C++ | |
Apache License 2.0 | 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.
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.
https://github.com/losfair/mvsqlite
-
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
-
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?
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].
[1] https://github.com/losfair/mvsqlite
[2] https://univalence.me/posts/mvsqlite-bench-20220930
- Show HN: mvSQLite v0.2
- mvsqlite: Distributed SQLite built on FoundationDB
-
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]
[0]: https://github.com/losfair/mvsqlite
[1]: https://news.ycombinator.com/item?id=32269287
- GitHub - losfair/mvsqlite: Distributed, MVCC SQLite that runs on FoundationDB.
fdb-document-layer
-
Turning SQLite into a Distributed Database
This is exactly what the engineers behind FoundationDB (FDB) wanted when they open sourced. For those who don't know, FDB provides a transactional (and distributed) ordered key-value store with a somewhat simple but very powerful API.
Their vision was to build the hardest parts of building a database, such as transactions, fault-tolerance, high-availability, elastic scaling, etc. This would free users to build higher-level APIs (Layers) APIs [1] / libraries [2] on top.
The beauty of these layers is that you can basically remove doubt about about the correctness of data once it leaves the layer. FoundationDB is one of the most (if not the) most tested databases out there. I used it for over 4 years in high write / read production environments and never once did we second guess our decision.
I could see this project renamed to simply "fdb-sqlite-layer"
[1] https://github.com/FoundationDB/fdb-document-layer
-
Cloudant/IBM back off from FoundationDB based CouchDB rewrite
https://github.com/FoundationDB/fdb-document-layer .and you get the transaction Al integrity.
I stopped using MongoDB and switched to this.
- FoundationDB Document Layer
- A truly open-source MongoDB alternative
- FoundationDB: A Distributed, Unbundled, Transactional Key Value Store [pdf]
What are some alternatives?
awesome-sqlite - A curated list of awesome things related to SQLite
foundationdb - FoundationDB - the open source, distributed, transactional key-value store
dqlite - Embeddable, replicated and fault-tolerant SQL engine.
badger - Fast key-value DB in Go.
litefs - FUSE-based file system for replicating SQLite databases across a cluster of machines
wasmer-postgres - 💽🕸 Postgres library to run WebAssembly binaries.
rqlite - The lightweight, distributed relational database built on SQLite.
npm-registry-couchapp - couchapp bits of registry.npmjs.org
datasette-stripe - A web SQL interface to your Stripe account using Datasette.
mosql - MongoDB → PostgreSQL streaming replication
blueboat - All-in-one, multi-tenant serverless JavaScript runtime.
dev-example-nosql-listener - This repository contains information on how to create and use a MariaDB MaxScale NoSQL Listener with MariaDB Community Server.