Yeah, I agree that your post was on-topic. It was automatically hidden when it received a number of flags from regular users. In any way, this forum doesn’t have a rule which says “You can’t write or edit posts with help of AI”, and I hope that moderators will make it visible once they have time to review it.
Asd
AstonJ
A few days ago we updated the flag system after having changed the post composition tip to the following a few weeks ago:
Type here. Use Markdown, BBCode, or HTML to format. Drag or paste images. Please use your own words (no AI slop please).
The flag system:
It’s AI Generated
Using AI as a smart dictionary, thesaurus, or translator is ok - using AI for content composition (or posting anything that looks like it) is not.
We’ve been monitoring AI generated posts in a log since Feb of last year and determined this is the best way forward for now.
If people want to post AI generated text/conversations, then the new section we created last year may be a good fit as it would ensure the flow of the main thread remains in line with expectations/the norm: https://forum.elixirforum.com/t/new-ai-conversations-section/72455 (we could probably update those guidelines now).
To the OP, you should be able to edit the post and submit a new version (just please make sure it’s in your own words - translated to English with the help of an AI is fine if need be).
4
syepes
It would be interesting to know how does it compare with KvRocks in terms of write & read performance. For the moment I have not found another K/V db that supports disk persistent that is faster.
0
yoavgeva
I didn’t run benchmark yet, because it’s not fully ready, so I can’t say numbers, I will tell you the arch comparison between both:
- Storage engine
- Ferricstore - uses Bitcask - an append-only log, every key location is always known, making every cold read O(1)
- Kvrocks - uses RocksDB - an LSM-tree. Reads traverse bloom filters → index blocks → data blocks across multiple levels. making every cold read O(log N)
- Memory & Read Path
- Ferricstore - has 2 tiers - ETS (hot, in-process hash table) → Bitcask on disk (cold)
- Kvrocks - even with a warm block cache, every lookup still traverses bloom filter → index block → data block — it’s a cache of disk structures, not a native hash table
- Write Path
- Ferric store has 2 modes
- quorum mode - which mean shard leader write to majority and he wait until all written and ACK by majority of nodes
- Async mode - shard leader save in ram send ack and than replace and write in disk
- KV rocks has only async, write to ram send ack to client than write to flush to disk
- Ferric store has 2 modes
- Write concurrency
- Ferricstore - Write in parallel across shards ( one shard per cpu) - this works with today NVMe which allow this to work - each shard has it’s own directory/files
- KV rocks - has multi threads but the write to disk is only one thread - even if they adapt to modern name they will need to change the arch to allow it
- Read concurrency (Hot Path)
- ferric store - lock-free ETS per shard
- KV rocks - uses partitioned index/filter blocks which splits the cache into shards with independent locks, reducing contention. But it’s still a shared structure with locking.
- Replication Model
- ferric store - Raft — all nodes in every shard’s group
- kvrocks - Async master/slave per slot
- Machines for 3-shard HA
- ferricstore- 3 total
- kvrocks - 6 (3 masters + 3 replicas)
- Read scaling (add nodes)
- ferric store - Automatic — every node serves local ETS reads
- kvrocks - Manual — explicit replica routing required
- External dependencies (to manage a cluster)
- ferric store - none
- kv rocks - Controller + etcd / ZK / Consul
Both use Redis spec, which mean for read concurrency they are not optimized, because the spec is tuned for Redis which is one thread, which mean each command arrived must return in the same order per connection.
Ferricstore has embedded mode for elixir/erlang which also mean it is not limited by rspec, so I expect even higher concurrency there.
Need to remember that the numbers of the benchmark also depend on machines, runtimes, etc.., and I don’t understand how they help, because in usage you don’t only do set/get you do a lot more, you need more features that allow more different stuff to do, so for example maybe Redis will be faster for your kind of work, but other kind of work Ferricstore or kvrocks will be better and faster, well I do understand that benchmark help in marketing 
1
ziinc
Benchmarks do not just “help with marketing”. You are asking busy developers to trust your solution on production projects, but won’t bother to do up even a simple Benchee benchmark to compare lookup speeds against existing libraries?
FWIW your library does target a very relevant use case for my day job, but I would not touch this with a 10 feet pole unless there is some effort made on code quality and performance assurance.
Some pointers:
- Your feature comparison table is against standalone caching components, which muddies the waters for your messaging on this as an Elixir library. There’s no comparisons against leading caching solutions like Cachex or Nebulex for example. Nor are there performance comparisons.
- Going through your readme without using AI is critical if you sent to win developer trust. The writing style is too indicative of AI tendencies without any critical editing. Your readme could be half the size with double the effectiveness in messaging.
- The standalone mode adds additional code and dependencies to the end user compilation, I would extract it out to a separate library if I were you.
If you want your caching solution to succeed in the Elixir space and community, it also has to address the concerns raised in such threads critically, as some have probably hand rolled similar solutions to what you are building in some shape or form.
2
yoavgeva
I agree with what you said overall, I never said that I won’t benchmark, I will compare with all relevant products as you see fit, with your own tests if you want.
I am saying I don’t expect that the results will be amazing benchmark wise for example the result be 10-20% worse than the solution for one node, people usually choose products because of this, I am trying to give something product wise which is SLA of 99.99% with simplicity of setup and ops, this features come at a cost of performance.
I agree that I need to polish the readme, guides and code quality, it’s only the start, but it nice to hear from you that this kind of solution have some merit in today world, that’s what I was searching for.
1
yoavgeva
Hey everyone,
Small update from my side.
Current version is `0.7.1` on Hex:
{:ferricstore, "\~> 0.7.1"}
The repo also moved to the org repo:
The direction also changed a lot from the first post.
The biggest change is that I moved from the Redis/RESP wire protocol in the standalone server to the Ferric native protocol.
That was intentional, because I want to support both things better: durable KV / Redis-style data structures, and FerricFlow workflows.
FerricStore still has the KV/data-structure side. The goal is still to support the useful Redis-style primitives: strings, hashes, lists, sets, sorted sets, TTLs, counters, locks, rate limits and so on.
But the main promise is not “any Redis client can connect and everything is a Redis drop-in” anymore. The current promise is more like: FerricStore is a durable native store with Redis-style data structures, and FerricFlow adds durable workflows and queues on top.
The thing I am more excited about now is FerricFlow: durable workflows on top of the same store.
The reason I started to move there is that I wanted a high throughput workflow engine, and I didnt find the thing I wanted.
In many projects I always ended up using queues for everything. Queue for this, retry queue for that, delayed queue, dead-letter queue, some DB table for status, some script to repair stuck jobs. It works, but after a while the real system is not the queue anymore, it is all the workflow state you build around it.
What I wanted was something with the speed and simple worker model of queues, but with the workflow state built in from the start.
The things FerricFlow is trying to solve are the things I always see people build around queues:
- durable workflow state
- leases and fencing
- retries and retry exhaustion
- history and audit
- signals
- value refs for big payloads
- fanout / child workflows
- indexed workflow metadata
- retention and repair
- governance controls
The native protocol gives me more control on the things both sides need: request ids, multiplexing, routing, backpressure, typed SDKs, leader hints, ACL behavior, KV commands, and workflow specific commands.
So KV is still supported and important. The direction is FerricStore native protocol with Redis-style data structures + FerricFlow workflows.
I also started using the HA cluster in my own projects already. In my company we also started using it for small stuff, and the feedback until now is very positive. It is not me saying “this is finished 1.0 production database”, but it is also not only a toy repo anymore. I am dogfooding it in real places, and that is helping me see what need to be better.
The numbers that are published now are for FerricFlow workflow/queue workloads. On the Azure 16-vCPU runs, the best balanced 32-shard runs show roughly:
- `54,060` workflows/s end-to-end (3 states), in the workflow-worker benchmark shape
These are not universal numbers, only the result for this workload and hardware.
I still need to rerun KV SET/GET with the current native SDK/protocol before I publish latest KV numbers. I also want better Elixir-facing comparisons with what people actually use here: Cachex, Nebulex, ETS based caches, and DB backed solutions.
What changed in the current release line:
- KV/data structures are still supported through the Ferric native protocol and embedded API.
- The direction is Redis-style primitives, not Redis wire-protocol compatibility as the main promise.
- FerricFlow is now the main focus: durable workflows built into FerricStore.
- Flow state has leases, fencing, retries, history, signals, value refs, fanout, retention, and indexed metadata.
- There is now a governance layer for workflows:
- budgets
- human approvals
- external effect tracking
- distributed limits
- circuit breakers
- governance ledger/debugging
The governance layer is the part I think is most intresting now.
The problem is not only “how do I run a job later?”.
It is:
- should this work retry?
- how many times?
- how much budget can it spend?
- does a human need to approve the next step?
- did an external side effect already happen?
- should a circuit breaker stop this provider call?
- is one tenant using too much capacity?
- why did this workflow pause, fail, or get denied?
If you also have this pain in your projects, give it a try you might like it
2
dimitarvp
Can you clarify whether durable work flows in this case is truly durable between application / database restarts?
0
yoavgeva
Yes, this is what I mean by durable here.
If any workflow command return success, the flow state was already written through FerricStore durable path before the ack.
So if the app / worker restart, the workflow is still there.
If FerricStore server restart, it should also recover the current flow state from the data dir / volume
and rebuild the hot indexes / projections from the durable state.
Important details:
- current flow state is the source of truth
- if worker dies while holding a lease, the flow is not lost
- after lease expire / reclaim, another worker can claim it again
- stale worker can’t complete old work because of lease / fencing tokens
- FerricFlow does not replay your handler code like Temporal
- external side effects still need idempotency keys
The model is durable workflow state (imagine persistence state machine), not durable code replay.
One caveat: you need to run FerricStore with persistent data dir / docker volume / disk. If you run on
tmpfs or delete the volume, of course there is nothing to recover from.
1