> The thing is, the rpmdb is unlike your average database. People expect to be
> able to access it both backwards and forwards in time across chroots,
> containers for builds, software inventory and whatnot. And when that ability
> is taken away (by introducing a new engine, or just an incompati
> And how about 15 years from now?
IMHO:
- Whatever storage engine was chosen now, this choice will look suboptimal in
15-25 years.
- The right strategy is to be able to choose easily, rather than trying to
choose the best engine "now & forever".
- A good tactic might be to add/replace an exp
> I also assume MDBX would be a more responsive upstream to our needs?
Yes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/958#issuecomment-559983635
@pmatilai, briefly **MDBX support 2 times longer keys than LMDB**.
In details:
- the key size limit depends from the database page size.
- for default (4K) pages MDBX now accepts keys up 1980 bytes (ie slightly less
than half the page size).
- but this value will soon be revised down to be sli
MDBX (i.e. [libmdbx](https://github.com/leo-yuriev/libmdbx)) is superior to
LMDB with set of additional features ([the
list](https://github.com/leo-yuriev/libmdbx#improvements-over-lmdb)). For rpmdb
most useful are:
1. Automatic on-the-fly database size control by preset parameters, both
reduct
