Hey,
I am sure i missing something but this thing really can help with flexibility
for James i think.
I do not think that flexibility is the most important thing.
James is already a large project and keeping it maintainable should be a very
high priority in my opinion.
With postgres, there is a storage system for small deployments and with
cassandra one for distributed deployments. I think this covers most use cases
while still being maintainable.
Best regards,
Felix
On 06/10/2026 10.35, Ilya Terskov wrote:
Cassandra is ACID now in 6/7 version (current master) because LWT -> Accord i
personally build it from sources (god that ant and accord build separately make me
wanna die) and even adopt it to windows (change some system calls) and hard test
it to oom killer, sigkill and other dirty stuff and it's not lost anything.
YouTrackDB surely interesting and company behind it already have this DB in
production (github show 0.5.0 snapshot idk its stable or not) its have FTS
Lucent integrated, full ACID, YQL,SQL,GQL (not fully), NoSQL (mosly like
MongoDB) and Graph (Gremlin+TinkerPop). I am sure i missing something but this
thing really can help with flexibility for James i think.
About tests. After full tuning postgres-app with S3 silo if you remember have
about 350-400 msg/seconds (when it was activemq) on my DDR4 32 GB 3200Mhz, i5
9400, Samsung 860 evo, for postres-app even 2nd Samsung 860 evo (so james on
one and postgresql on second, windows system on third (also samsung 980 evo)
perfect i think?) but for more correct testing lets use only YouTrackDB
(embedded mode) and Postgres-APP all messages inside (blobs included).
All tests were on the current master build from sources without special tuning
(default i mean, youtrackdb full acid mode)
вт, 6 окт. 2026 г. в 14:00, Benoit TELLIER via server-dev <[email protected]
<mailto:[email protected]>>:
Cassandra is not ACID. Please read
https://cassandra.apache.org/doc/stable/cassandra/architecture/guarantees.html
<https://cassandra.apache.org/doc/stable/cassandra/architecture/guarantees.html>
MongoDB won't hold scale well.
PostgreSQL is a versatile tool that shines at medium / low volumes, is an
admin standard and have options for large scale. I expect most users to go with
vanilla PG server and just be fine - the question is raised at scale only IMO.
For the record we made the choice of PG and not regular SQL in order to
rely on PG built in queries and datatype in order to deliver a more efficient
implem than raw SQL.
YouTrackDB is an interesting experiment, and I'm happy to see people
exploring alternatives. However, every new backend adds a maintenance burden
for the project. Historically we have removed backends that lost their
maintainers. So adding one upstream needs more than a working implementation:
we need a community willing to maintain it over time.
About the 400 msg/s, could you share your benchmark methodology: hardware,
James version, mail size, concurrency? Comparing against the postgres-app on
the same setup would make the numbers meaningful. As for hot backups,
PostgreSQL has mature tooling (pg_basebackup, WAL archiving / PITR), and the
blob store can sit on S3 or the file system with ts own backup strategy. Also
raw SMTP throughput is not a limiting part of most James systems I did operate
on.--
Best regards,
Benoit TELLIER
General manager of Linagora VIETNAM.
Product owner for Twake-Mail product.
Chairman of the Apache James project.
Mail: [email protected] <mailto:[email protected]>
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
Le oct. 6, 2026 5:40 AM, de Ilya Terskov <[email protected]
<mailto:[email protected]>>Hi guys! :) i really think for home users and anykey
level of admins still
prefer more straight databases then Postgres (like MongoDB) and that
because there so many versions of Postgres
(YugabyteDB, TimescaleDB, Tantor, Postgres Pro and there ALOT) also as i
see NoSQL DB with ACID like Xodus or MongoDB (even YouTrackDB nosql+graf
show better and pretty easy to adopt
github.com/prosgarz35/youtrackdb-app
<http://github.com/prosgarz35/youtrackdb-app>) better fit for mail server
specifics. Postgres is surely good, but i personally after try Cassandra i
like it more (mb i rly like java tools?) and its shame there no way i can
use it on standalone server because of ACID (i try to hard test it and no
corruption but still...). So i feel like something like Jpa-App but
new...cause current Jpa-App can be pretty easy corrupt by oom killer,
sigkill etc. Youtrackdb seems promising by the way - i adopt all into this
Database (even mail spooler) and it show about 400 msg/sec, full ACID,
online hot backups (full and incr) with sync on blobs in filesystem. Tell
me you thoughts about it please.
пн, 5 окт. 2026 г. в 18:34, Benoit TELLIER via server-dev <
[email protected] <mailto:[email protected]>>:
> Hello
>
> jpa-app neing deprecated -> +1
>
> About xodus: I see the point but I am reluctant to add yet another family
> of storage dependency as part of the james project.
>
> I'd consider the PG dependency light enough to not be a concern even to
> self hosters.
>
> I'd recommend concentrating our efforts only to one backend instead of
> dispersing our efforts.
>
> --
>
>
> Best regards,
>
> Benoit TELLIER
>
> General manager of Linagora VIETNAM.
> Product owner for Twake-Mail product.
> Chairman of the Apache James project.
>
> Mail: [email protected] <mailto:[email protected]>
> Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
>
>
>
> Le oct. 5, 2026 9:26 AM, de Ilya Terskov <[email protected]
<mailto:[email protected]>>i think
> its not worth it only bacause in future if james bump java to 25+
> there no way for xodus still be working :c sorry to wasting you time...
but
> i still try youtrackdb github.com/JetBrains/youtrackdb
<http://github.com/JetBrains/youtrackdb> - database
> which used now instead of xodus.
>
> пн, 5 окт. 2026 г. в 12:24, Ilya Terskov <[email protected]
<mailto:[email protected]>>:
>
> > Thanks Rene!
> >
> > here is PR POC
> >
> > github.com/apache/james-project/pull/3231
<http://github.com/apache/james-project/pull/3231>
> >
> > пн, 5 окт. 2026 г. в 09:25, Rene Cordier <[email protected]
<mailto:[email protected]>>:
> >
> >> Hi Ilya,
> >>
> >> I personally don't know Xodus at all.
> >>
> >> I would say if you can propose a POC that separates well Xodus implem
> >> into its own modules without impacting much the rest of the code it's
> >> maybe ok having a look and discussing around it.
> >>
> >> The more we add components support to James the moire we need time and
> >> energy to keep maintaining everything though keep in mind.
> >>
> >> Rene.
> >>
> >> On 10/4/26 22:25, Ilya Terskov wrote:
> >> > Hi there once again.
> >> >
> >> > I am little update build. I know its will adds complexity if added
to
> >> > master but i think its good option vs jpa-app which now mostly
> >> deprecated
> >> > and not more main point of development. I am personaly want hard
test
> it
> >> > and support as i can.
> >> > For now in my repo its uses in memory spooler (because activemq ->
> >> artemis
> >> > transition time) also for simplicity i make metadata and blob in
> >> database
> >> > but xodus support and control meta in database and blob in
filesystem
> -
> >> and
> >> > with backup it sync both places and guarantee persistent - its
killer
> >> > feature dont it?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
> >> For additional commands, e-mail: [email protected]
<mailto:[email protected]>
> >>
> >>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---
Gesellschaft für interkulturelles
Zusammenleben gGmbH (GIZ)
Felix Auringer
IT
Reformationsplatz 2
13597 Berlin
Tel: 030/513 0100 00; Fax: 030/513 0100 09
www.giz.berlin; [email protected]
Amtsgericht Charlottenburg HRB 200872 B
Geschäftsführerin: Dr. Britta Marschke
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]