Alternatives
Products that do what T4 – a versioned datastore with branching and time-travel (S3-backed) does
Hi HN, I built t4, a datastore that stores its WAL and snapshots in S3. Instead of traditional storage, it writes append-only segments to object storage and reconstructs state from checkpoints + WAL. A side effect of this model is that the database becomes naturally versioned: you can restore any past state, branch from any point (with copy-on-write) and replay history I started this as an experiment to replace etcd in Kubernetes, but it’s evolving into a general-purpose versioned state store. Curious what people think about it and appreciate any feedback!
- 1
- 2CS
We started CallFS after yet another late-night “why did the uploads vanish?” incident. Our small team had stitched together rsync, a fragile NFS mount, and an S3 bucket—none of it observable, all of it waiting to bite us. So we wrote a single-process file service in Go that: • Speaks the S3 API (so existing tooling works). • Stores hot data on local disks for speed; cold data can sit in any S3-compatible bucket. • Exposes Prometheus metrics and JSON logs by default, because “what happened?” shouldn’t be guesswork. • Ships as a ~25 MB static binary—no external deps, MIT license. Today it’s…
2025 · github.com
- 3SV
I've already posted yesterday, but I'd really love to get comments, any kind of questions, suggestions and help would be greatly appreciated as it's an Open Source project of mine (and was for others during my studies at the University of Konstanz 6 years ago). Since then I spent countless ours to bring forth the idea of a versioned storage system, especially well suited for analytical tasks for timd-varying data. Especially I'd love to discuss what documentation you need, which next steps are necessary (JSON, Cloud...), API additions or changes... I've updated the README quiet a bit, such…
2018
- 4WS
I’ve been in the MLOps space for ~10 years, and data is still the hardest unsolved open problem. Code is versioned using Git, data is stored somewhere else, and context often lives in a 3rd location like Slack or GDocs. This is why we built XetHub, a platform that enables teams to treat data like code, using Git. Unlike Git LFS, we don’t just store the files. We use content-defined chunking and Merkle Trees to dedupe against everything in history. This allows small changes in large files to be stored compactly. Read more here:…
2022 · xethub.com
- 5LC
Hi, most people (hopefully) have local backups. However, when that backup fails, it is good to have a backup stored somewhere off-site. In the old days you would ship physical drives/tapes, which is cumbersome, costly, and slow. With fast upload speeds, it is now possible to upload your data to the cloud. I have found S3 Glacier Deep Archive to be a great solution for this: - It is very cheap ($1/TB/month for US region) - Very reliable (99.999999999% data durability, data spread over 3 Availability Zones) However, usability out of the box is not that great, I'm not aware of…
2022 · github.com
- 6SS
I'm developing a storage system for versioning data at the subfile level, especially well suited for SSDs due to its log-structured COW nature. It implements a novel versioning algorithm called sliding snapshot, a diff-algorithm which makes use of our stable record-identifiers and optionally hashes, another diff algorithm for importing similar XML-documents as a versioned resource as well as novel XPath axis to navigate not only in space, but also in time. Recently, I've implemented a higher level, asynchronous REST-API with Kotlin (Coroutines) and Vert.x in a seperate module. The system is…
2018
- 7SL
S2 was on HN for our intro blog post a year ago (https://news.ycombinator.com/item?id=42480105). S2 started out as a serverless API — think S3, but for streams. The idea of streams as a cloud storage primitive resonated with a lot of folks, but not having an open source option was a sticking point for adoption – especially from projects that were themselves open source! So we decided to build it: https://github.com/s2-streamstore/s2 s2-lite is MIT-licensed, written in Rust, and uses SlateDB (https://slatedb.io) as its storage engine. SlateDB is an…
Jan 2026 · github.com
- 8RL
We'd love to share our work with you: Restate, a system for workflows-as-code (durable execution). With SDKs in JS/Java/Kotlin and a lightweight runtime built in Rust/Tokio. https://github.com/restatedev/ https://restate.dev/ It is free and open, SDKs are MIT-licensed, runtime permissive BSL (basically just the minimal Amazon defense). We worked on that for a bit over a year. A few points I think are worth mentioning: - Restate's runtime is a single binary, self-contained, no dependencies aside from a durable disk. It contains basically a…
2024 · restate.dev
- 9SP
This is a MVP for Serverless Postgres. 1/ It uses Fly.io[0], which can automatically pause your database after all connections are released (and start it again when new connections join). 2/ It uses Oriole[1], a Postgres extension with experimental support for S3 / Decoupled Storage[2]. 3/ It uses Tigris[3], Globally Distributed S3-Compatible Object Storage. Oriole will automatically backup the data to Tigris using background workers. I wouldn't recommend using this in production, but I think it's in a good spot to provoke some discussion and ideas. You can get it running…
2024 · github.com
- 10IB
Every data pipeline job I had to tackle required quite a few components to set up: - One tool to ingest data - Another one to transform it - If you wanted to run Python, set up an orchestrator - If you need to check the data, a data quality tool Let alone this being hard to set up and taking time, it is also pretty high-maintenance. I had to do a lot of infra work, and while this being billable hours for me I didn’t enjoy the work at all. For some parts of it, there were nice solutions like dbt, but in the end for an end-to-end workflow, it didn’t work. That’s why I decided to build an…
2024 · github.com
- 11AB
we've been working on a KV store for the past year or so which is 2-6x faster than Redis (benchmark link below) yet disk persisted! so you get the speed of in-memory KV stores but with disk persistence. To achieve this we've created our custom filesystem that is optimized for our special usecase and we're doing smart batching for writes and predictive fetching for reads. In addition to basic operations, it also provides atomic inc/dec, atomic json patch, range scans and a unique key monitoring mechanism (pub-sub) over WebSockets which essentially allows you to receive notification on…
2025 · hpkv.io
- 12
- 13
- 14DT
Hi HN - Peter from DBOS here with my co-founder Qian (qianl_cs) Today we want to share our TypeScript library for lightweight durable execution. We’ve been working on it since last year and recently released v2.0 with a ton of new features and major API overhaul. https://github.com/dbos-inc/dbos-transact-ts Durable execution means persisting the execution state of your program while it runs, so if it is ever interrupted or crashes, it automatically resumes from where it left off. Durable execution is useful for a lot of things: - Orchestrating long-running or…
2025 · github.com
- 15
- 16PD
PicoMQ is a Rust server for Durable Streams, built on Object Store. Cheap, URL-addressable, granular streams (create/append/read/long-poll/SSE), with Pico Protocol or Durable Streams Protocol as the facade. S3Stream is the stream storage primitive, used in AutoMQ, shipped as a Rust library. Coordination is a command log in Postgres.
13d ago · picomq.com
- 17MD
Hi HN, I'm Emilie, I have a literature background (which explains the well-written documentation!) and I've been learning Rust and distributed systems by building minikv over the past few months. It recently got featured in Programmez! magazine: https://www.programmez.com/actualites/minikv-un-key-value-st... minikv is an open-source, distributed storage engine built for learning, experimentation, and self-hosted setups. It combines a strongly-consistent key-value database (Raft), S3-compatible object storage, and basic multi-tenancy. Features/highlights: - Raft…
Feb 2026 · github.com
- 18SA
We just released our database, SpacetimeDB, on GitHub under the BSL 1.1 license. It converts to a free software license after a few years. The point of the database is that you upload application logic into the database as a WebAssembly stored procedure, so instead of clients connecting to a webserver they connect directly to the database. The database itself does authentication and you write your own authorization logic just like you would inside a webserver. We’ve developed our game, BitCraft (https://bitcraftonline.com) entirely in this way. All of the game state is stored and…
2023 · github.com
- 19DD
Jun 2026 · github.com
- 20GA
Hey HN, We've been experimenting with a real-time, version-controlled NoDB for Deno & React called GoatDB. The idea is to remove backend complexity while keeping apps fast, offline-resilient, and easy to self-host. Runs on the client – No backend required, incremental queries keep things efficient. Self-hosted & lightweight – Deploy a single executable, no server stack needed. Offline-first & resilient – Clients work independently & can restore state after server outages. Edge-native & fast – Real-time sync happens locally with minimal overhead. Why We Built It: We needed something that’s…
2025 · github.com
- 21
- 22
Document database with no database server. Tiny, LLM-friendly TypeScript API; DB engine runs to completion in each JS request handler; state lives in S3/R2. - Gusto/baerly-storage
Jul 2026 · github.com
- 23TM
I built tinykv because I kept reaching for simple persistent storage in Rust projects but found existing solutions either too complex (sled) or unmaintained (pickledb). tinykv focuses on simplicity: JSON-based, serde-powered, with optional TTL. Perfect for CLI tools, game saves, config storage. Would appreciate any feedback from the HN community!
2025 · crates.io
- 24SA
SlateDB is an embedded storage engine built as a log-structured merge-tree. Unlike traditional LSM-tree storage engines, SlateDB writes data to object storage (S3, GCS, ABS, MinIO, Tigris, and so on). Leveraging object storage allows SlateDB to provide bottomless storage capacity, high durability, and easy replication. The trade-off is that object storage has a higher latency and higher API cost than local disk. To mitigate high write API costs (PUTs), SlateDB batches writes. Rather than writing every put() call to object storage, MemTables are flushed periodically to object storage as a…
2024 · github.com
Ranked by how close each launch is in meaning, then by votes. Refine with a description →