Если бы было достаточно, тогда не приходилось бы прибегать к BigInt.

Чаще всего Array действительно быстрее)

class ItemList {
        next = null;
        prev = null;
        operation;
        constructor(operation) {
            this.operation = operation;
        }
    }

    class List {
        first = null;
        last = null;
        constructor(){}
        add(item) {
            this.first ??= item;
            item.prev = this.last;
            if(this.last)
                this.last.next = item;
            this.last = item;
            return this;
        }
    }

    const list = new List();
    const arr = [];
    const NA = 1_000_000;
    let na;


    na = NA;
    console.time('list');
    while(na--) list.add(new ItemList(na));
    console.timeEnd('list');


    na = NA;
    console.time('arr');
    while(na--) arr.push(na);
    console.timeEnd('arr');

Насколько корректно проведено тестирование?)

voraa, а на сколько большой может быть такой массив данных?

Какой именно?
Если массив operations, то это зависит от ваших условий. Сколько там операций у вас идет?
Про Map точно не знаю ограничений, но пару миллионов точно влезает.
Где то читал про объекты, вроде нельзя больше 8 миллионов полей. Думаю для Map примерно такое же ограничение.
Ну и разумеется, должно хватить памяти у компа.

Суть в том, что изучили все возможные БД и SQL, и NoSQL, и NewSQL... И реляционные, и документоориентированные, и колоночные...

Вот колоночные как-то больше всего подходят (именно архитектура). Но по итогу ни одна из них не подходит.

Понятное дело, что безграничные данные хранить в JS - тоже не выход, т.к. всё таки есть ограничения у JS движков. Но как вариант — хранить это в JS, а потом просто огромной пачкой сгружать на диск и хранить в виде столбцов.

Либо, допустим, построчно хранить операции в файле — типа как лог. А отдельно ещё сделать в виде колонок — чтобы иметь мгновенный доступ к требуемым данным. Например, в одной колоночной БД — реализован механизм, который создаёт виртуальные колонки, отсортированные по конкретной колонке:

Н-р, в нашем случае есть 3 основных столбца — from, to, amount. Если представить их в хронологическом порядке, то в столбце amount всё идет как попало и сложно что-либо найти быстро. Для этого создаётся отдельная колонка (или "представление") в котором все данные отсортированы по порядку — как результат мы можем использовать либо бинарный поиск, либо ваще интерполирующий (вот бы ещё понять как его на строки перевести).

По итогу ограничение данных просто отсутствует.

Тогда только думать про БД. С индексами и все как положено.
Рассмотрите Mongo, как вариант.
Но с любой БД вы не получите таких скоростей, как с хранением в оперативной памяти
Все таки хранение на диске, считывание индексов, самих данных....
О временах в пределах нескольких мс на операцию можно не мечтать.

Mongo была вдоль и поперек рассмотрена. Это вообще не то.

Хм, а если тогда использовать несколько серверов? Типа в тех же колоночных БД данные хранятся в файлах размером до 256 МБ.

Получается вместо файла просто будет отдельный веб-сервер. :D

Кстати, в колоночной БД — колонки сами по себе являются индексами.

voraa,
или как-то может виртуальных серверов?

Не знаю. Совсем не спец по архитектуре серверов. В любом случае надо будет смотреть, что там с временами запросов будет.