KVRock vs Redis Same API Different performance profile
TLDR Kvrocks offers disk key value store compatible with redis API We qualified it and it shines eg for RSpamd per user bayesian database It is not fit as a generic purpose cache: for this we have PG / Cassandra Redis == Valkey we can update James to reflect this community shift. It's a drop in replacement, and I use the 2 interchangably. And all users can choose what they plug behind "Redis". -- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Twake-Mail product. Chairman of the Apache James project. Mail: [email protected] Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) On Sep 24, 2026 1:13 PM, from Ilya Terskov <[email protected]>About redis, there Apache Kvrocks dont it? It have redis protocol compability of i know right. Why redis and not Valkey or Kvrocks? Embeddeding Kvrocks seems cool and fast. чт, 24 сент. 2026 г., 18:03 Benoit TELLIER via server-user < [email protected]>: > > Sorry about this lots of PR dear Benoit :) > > No big deal ! > > > I just really think about where to migrate, stalwart have some > problems,postfix+dovecot... > > I would be happy to here more about that. > > And we will indeed together bring James + PG to the level you want it. > > There's a real role to take to make James + PG easy enough for self > hosters to use it. If you wish to contribute in that direction it would be > really appreciated. > > > So i want find all critical edge cases that can lead to data corruption > BEFORE moving on James. > This kind of review is indeed really welcome! > > > So please dont be mad at me guys who reviews all this. > > I'm not mad. I'm sorry to be the guys that says "no". I understand > newcomers can't get why some decisions were made, and it's my role to > explain. I would consider the process we currently undergo as extremely > healthy.> The more feedback i got the more i populate my I database to make > more correct and dry PRs. > > +1 also if something surprises you don't hesitate to ask i=on the mailing > list. > > We probably want to switch techie discussions related to contributions to > [email protected] > > > warming > > well JVM does an incredible job on prod. For us it is a non-topic... > > > caching > > I have indeed concerns about repeated reads on mailbox, acl mostly. > > I have in mind a Redis based cache populated on read with configurable > expiration with mailbox listener built in invalidation as a design > (critical to achieve most of the time instant propagation of the changes to > the cache). One day mailbox/redis maybe ! > > Slightly more complex than in memory caching > But distributes and scale (redis cluster). That's undocumented and on the > back of my head but I would be happy to sheperd something going in that > direction.-- > > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM. > Product owner for Twake-Mail product. > Chairman of the Apache James project. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > On Sep 24, 2026 12:17 PM, from Ilya Terskov <[email protected]>Sorry > about this lots of PR dear Benoit :) > I just really think about where to migrate, stalwart have some problems, > postfix+dovecot... Lets say i cant live with that low flexibility. So i > want find all critical edge cases that can lead to data corruption BEFORE > moving on James. > > So please dont be mad at me guys who reviews all this. The more feedback i > got the more i populate my I database to make more correct and dry PRs. > > After all critical things i move to optimise - warming, caching etc. >
