Alarming Performance when using LiteDB for simple record saving

I had a requirement for a certain application where a large number of messages will be received and they need to be stored. so I chose LiteDB and used it with default configuration as mentioned in the documentation. Here is the class that I used:

    public class HolderMessage
    {
        public long Id { get; set; }
        public GridMessageType MessageType { get; set; }
        public HolderMessageState State { get; set; }
        public DateTime AddedOn { get; set; }
        public byte[] Message { get; set; } 
     }

In some other class

        public Database(FileInfo file)
        {
            _db = new LiteDB.LiteDatabase(file.FullName);

            _inbox = _db.GetCollection<HolderMessage>("Inbox");
            _outbox = _db.GetCollection<HolderMessage>("Outbox");


            Action<LiteDB.LiteCollection<HolderMessage>> PrepareIndex = (arg) =>
            {
                arg.EnsureIndex(x => x.Id, new LiteDB.IndexOptions { EmptyStringToNull = true, Unique = true, TrimWhitespace = true });
                arg.EnsureIndex(x => x.AddedOn, new LiteDB.IndexOptions { EmptyStringToNull = true, Unique = false, TrimWhitespace = true, IgnoreCase = true });
                arg.EnsureIndex(x => x.MessageType, new LiteDB.IndexOptions { EmptyStringToNull = true, Unique = false, TrimWhitespace = true });
            };

            PrepareIndex(_inbox);
            PrepareIndex(_outbox);
        }

yet at some other location I’m saving the messages

        public void Push(Message msg)
        {
            var mail = new HolderMessage
            {
                Id = ++_counter,
                AddedOn = DateTime.Now,
                MessageType = msg.Kind,   // this is enum
                Message = Common.Utility.Serialize(msg),   // this returns a byte array
                State = HolderMessageState.UnProcessed  // this is an enum
            };

            _queue.Insert(mail);
        }

and when we call Push() during testing, it gave the shockingly poor performance ever

            var watch = new System.Diagnostics.Stopwatch();
            watch.Start();
            for(var i = 1; i<10000;i++)
                storage.Inbox.Push(CreaterMessage(new List<string> { $"Message:{i}" }));
            watch.Stop();

so what exactly is wrong? is the configuration a problem or something else? because as the code is, it gives 20 records per second speed. i.e 10,000/ watch.TotalSeconds

[SuheylZ]

but why would a database not perform adequately at regular operations and insist on bulk operations? That is something I do not understand. I cannot use Sql Server because the app I’m working on is a small one that will run as a part of bigger app. All I wanted to use LiteDB for, was persistent cache which now I feel was a wrong choice.

My conclusion is

liteDB may be an ambitious effort and maybe a tool of interest for hobbyists but it is nowhere near production ready & cannot be used in serious development

[nerai]

@MercedeX You’re saying you need a database able to perform 10000 operations per second. If a disk based DBMS seems to have more than that, it uses caching, either internally or via the OS. Since you insist that this violates your consistency model (else bulk insertion would be possible), all changes must be flushed to disk immediately. Before that, obviously, the database has to read at least its header for each operation. Never mind that it probably has to read a few more pages.

So all of the 10000 operations require at least 1 disk read and write naturally, on a regular HDD instead of an SSD. Regular hard disks physically do not support this. For instance, a 15k rpm SAS drive has only around 200 IOPS. So if you find any offline DBMS that can actually do what you want, let me know.