service-fabric VS ScaleStore

The first on the list is the entry project .sfproj. They use a non-SDK-style project template with a bunch of .xml files for configuration but with no C# code. They require Fabric.MSBuild nuget to build and package Service Fabric apps. Unfortunately, the dotnet add package command won't update dependencies since they only support and non-SDK-style project template uses the package.config file to manage dependencies.

Proprietary in what way?

Setup your ASP.NET app as a scaleable service that can run in a distributed fashion. You may be able to use something similar to Service Fabric to help - https://github.com/microsoft/service-fabric

Considerable amount of Azure Service Fabric is written in C# https://github.com/microsoft/service-fabric. As many people mentioned already, until .NET Core, no platform developers really cared about C#. Perhaps in future we may see interesting things happen with a lot of performance optimisations coming to C# as well.

I don't remember exactly why I have any of them saved, but these are some experimental data stores that seems to be fitting what you're looking for somewhat:

- https://github.com/DataManagementLab/ScaleStore - "A Fast and Cost-Efficient Storage Engine using DRAM, NVMe, and RDMA"

- https://github.com/unum-cloud/udisk - "The fastest ACID-transactional persisted Key-Value store designed for NVMe block-devices with GPU-acceleration and SPDK to bypass the Linux kernel."

- https://github.com/capsuleman/ssd-nvme-database - "Columnar database on SSD NVMe"

The linked blog post at the top of this article - https://muratbuffalo.blogspot.com/2023/01/is-scalable-oltp-i... - provides graphics that give extremely useful context. And here's the repo for the paper that discusses: https://github.com/DataManagementLab/ScaleStore

The idea that one of many writer-compute-nodes can literally reach into a memory buffer that is shared across machines, atomically flip some lock bits and propagate some cache-coherence messages, and use that to build a multi-writer distributed database without needing to partition (and where any writer-compute-node can handle any message, so you can just round-robin a firehose of messages at them)... and that there's a chance (though not yet implemented) that one could implement ACID on top of this? It's absolute madness, and wildly exciting.