Refound Alternatives

Similar projects and alternatives to refound

mvsqlite

26 1,323 0.0 Rust refound VS mvsqlite

Distributed, MVCC SQLite that runs on FoundationDB.
datascript

25 5,359 7.7 Clojure refound VS datascript

Immutable database and Datalog query engine for Clojure, ClojureScript and JS
InfluxDB

www.influxdata.com featured

Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
foundationdb

21 14,012 9.8 C++ refound VS foundationdb

FoundationDB - the open source, distributed, transactional key-value store
tigris

20 887 8.6 Go refound VS tigris

Tigris is an Open Source Serverless NoSQL Database and Search Platform.
relic

13 395 3.6 Clojure refound VS relic

Functional relational programming for Clojure(Script).
Permazen

10 397 9.2 HTML refound VS Permazen

Language-Natural Persistence Layer for Java
shuttle

4 573 6.9 Rust refound VS shuttle

Shuttle is a library for testing concurrent Rust code (by awslabs)
SaaSHub

www.saashub.com featured

SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
fdb-record-layer

4 564 9.8 Java refound VS fdb-record-layer

A record-oriented store built on FoundationDB
hyhac

1 12 10.0 Haskell refound VS hyhac

A HyperDex Haskell Client
tuple-database

4 392 5.2 TypeScript refound VS tuple-database

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better refound alternative or higher similarity.

Suggest an alternative to refound

refound reviews and mentions

Posts with mentions or reviews of refound. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-07-03.

FoundationDB: A Distributed Key-Value Store
13 projects | news.ycombinator.com | 3 Jul 2023

100%. I don't have the time to read the paper but online schema changes, with the ability to fail and abort the entire operation if one row is invalid, are basically the same problem as background index building.
If instead of using some generic K/V backend, it made use of specific FDB features, it might be even better. Conflict ranges and snapshot reads have been useful for me for some background index building designs, and atomic ops have their uses.
It is not necessary to store a version on each row. I can't remember why I did things this way, but https://github.com/srh/refound has no versions on persisted objects, has online background index building, and could do schema updates the same way. (That system doesn't have schemas.) When there is an active index build, incoming writes already read about active index build ranges and can participate in index building if it's interfering with their keys, to avoid starving it out if they're hammering the table with writes. So they know based on the ranges which keys have index entries. Adding versions would be sensible for performance reasons, and it would also minimize the occasions that writes have to read sindex build metadata while supporting this starvation mitigation.
> Oh yes, it also has a Raft implementation, so if you want multi-cluster FDB with Raft-driven failover you could do that too (iirc, FDB doesn't have this out of the box).
I don't know what you mean by this. Multiple FDB clusters?