mehrant

Feel free to test for yourself :)

Test was done using Redis benchmark for 1M random keys, 50 clients, Pipeline depth, 64.

I did this locally on my MBP M3-Max. This gives a little over 2M for Redis and 5.4M for Feox.

redis-benchmark -n 1000000 -r 1000000 -c 50 -P 64 -t SET,GET -q

https://x.com/mltoosi/status/1963599382592590069?s=46

Feox DB itself (the embedded KV behind the server) is quite fast as well. You can also test for yourself or see the criterion benchmark report.

https://feoxdb.com/benchmarks.html

<700ns INSERT and <200ns GET on Feox DB itself.

The Redis-compatible server is based on Feox DB, which is an embedded KV Store in Rust.

https://github.com/mehrantsi/feoxdb

When operations complete in 200ns instead of blocking for microseconds/milliseconds on fsync, you avoid thread pool exhaustion and connection queueing. Each sync operation blocks that thread until disk confirms - tying up memory, connection slots, and causing tail latency spikes.

With FeOxDB's write-behind approach:

  - Operations return immediately, threads stay available

  - Background workers batch writes, amortizing sync costs across many operations

  - Same hardware can handle 100x more concurrent requests

  - Lower cloud bills from needing fewer instances

The durability tradeoff makes sense when you realize most KV workloads are derived data that can be rebuilt. Why block threads and exhaust IOPS for fsync-level durability on data that doesn't need it?

Thanks for the comment. :)

The target use cases include:

1- Session stores (can be reconstructed from auth service) 2- leaderboards/counters (recent scores/counters can be recalculated) 3- Real-time analytics/metrics (losing ~100ms of metrics is acceptable) 4- Caching layers with upstream persistence 5- High-frequency systems where latency > everything

I generally think that for KV stores, there are more use cases that can accept this _slightly_ relaxed durability model than not. of course this isn't the case for a main DB. KV stores often handle derived data, caches, or state that can be rebuilt.

That said, for cases needing stronger durability, you can call flush_all() after critical operations - gives you fsync-level guarantees. Also considering adding a "sync" or "Full ACID" mode that auto-flushes on every write for users who want strong durability.

The philosophy is: make the fast path really fast for those who need it, but provide escape hatches for stronger guarantees when needed.

Thanks! yeah, SQLite's write lock is painful for concurrent apps. I'm comfortable with kernel development, so I brought some of those patterns here - RCU-style lock-free reads, per-CPU inspired sharded buffers, and io_uring for kernel-bypass I/O. would love to hear your thoughts if you had the chance to give it a spin :)

Reading your comment about comparing the throughput to Redis, it seems to me that you haven't read the benchmark article really. In there, we're in fact comparing the "throughput" and not the latency. allow me to quote some of the throughput numbers from the article mentioned above:

Single Operation Performance

Redis Single Operations

SET: 273,672.69 requests per second (p50=0.095 ms)

GET: 278,164.12 requests per second (p50=0.095 ms)

HPKV Single Operations

INSERT: 1,082,578.12 operations per second

GET: 1,728,939.43 operations per second

DELETE: 935,846.09 operations per second

Batch Operation Performance

Redis Batch Operations

SET: 2,439,024.50 requests per second (p50=0.263 ms)

GET: 2,932,551.50 requests per second (p50=0.223 ms)

HPKV Batch Operations

INSERT: 6,125,538.03 operations per second

GET: 8,273,300.27 operations per second

DELETE: 5,705,816.00 operations per second

The latency of 600ns as I mentioned is a local vectored interface call and not over the network. the is not how we compared the system with Redis. the above numbers are using our RIOC API over the network, in which HPKV behaves like a server similar to a Redis server.

The numbers above are compared with Redis in-memory and HPKV is still 2-6x faster. even if you assume HPKV as just an in-memory KV store with no persistence.

One thing we'd like to know your opinion on, is our key monitoring via WebSocket (pub-sub) feature. You can read more about it in our documentation under WebSocket.

Is it something that you think it's useful and you might have use case for or you can't see any value in it? In other words, is it something that you might consider using HPKV because of it?

Thank you for your thoughtful critique.

To clarify what our numbers actually mean and address your main question of "what does that number actually mean":

1- The 600ns figure represents precisely what you described - an in-memory "write done" where memory structures are updated and the data becomes globally readable to all processes. This is indeed comparable to what Redis without persistence or memcached provides. Even at this comparable measurement basis (which isn't our marketing gimmick, but the same standard used by in-memory stores), we're still 2-6x faster than Redis depending on access patterns.

For full persistence guarantees, our mean latency increases to 2582ns per record (600ns in-memory operation + 1982ns disk commit) for our benchmark scenario with 1M records and 100-byte values. This represents the complete durability cycle. This needs to be compared with for example Redis with AOF enabled.

2- I agree that the meaning of "write done" requires clear context. We've been focusing on the in-memory performance advantages in our communications without adequately distinguishing between in-memory and persistence guarantees.

We weren't trying to hide the disk persistence number, we simply used "write done" because in our comparison we compared with Redis without persistence. but mentioning the persistence made an understandable confusion. that was bad on our part.

Based on your feedback, we'll update our documentation to provide more precise metrics that clearly separate these operational phases and their respective guarantees.

UPDATE:

clarification on mean disk write measurement:

the mean value is calculated from the total time of flushing the whole write buffer (parallel processing depending on the number of available cpu cores) divided by the number of records. so the total time for processing and writing 1M records as described above was 1982ms which makes the mean write time for each record 1982ns.

for the time being, have a look at this please: http://hpkv.io/videos/performance_local.webm

this is 1M records, 3M operations on a single node, single thread, recorded in real time (1x).

I understand that without access to the source of test program it's hard to trust, but we can arrange that if you decided to take on that call :)

our p50 is indeed 600ns for write, the way I explained it. I understand that at this point, this can be read as "trust me bro" kind of statement, but I can offer you something. we can have a quick call and I provide you access to a temp server with HPKV installed on it, with access to our test suit and you'll have a chance to run your own tests.

this can be a good learning opportunity for both of us (potentially more for us) :)

if you're interested, please send us an email to support@hpkv.io and we can arrange that

thanks for the feedback :)

our main target for "performance" value proposition are companies and businesses which will setup HPKV either locally (Enterprise plan) for nanosecond performance or in the cloud provider of their choosing, and working via RIOC API (Business Plan), getting ~15 microsecond range over network. however you're totally right, that doesn't really matter much if you're using it REST or WebSocket. for Pro tier, our value proposition is still the fastest managed KV store (you still get <80 ms for writes with a ~30ms ping to our servers) and features such as bi-directional WS, Atomic operations and Range Scans on top basic operations.

but given your comment, I think we should perhaps rethink how we're presenting the product. thanks for the feedback again :)

thank you :) it would be interesting to have a chat for sure. would you mind dropping an email on the email I mentioned in OP and I'll reach out to you.

your concern is understandable. we'll be in touch :)

We provide some elements of ACID guarantees, but not full ACID compliance as traditionally defined in database systems:

Atomicity: Yes, for individual operations. Each key-value operation is atomic (it either completes fully or not at all).

Consistency: Partial. We ensure data validity through our conflict resolution strategies, but we don't support multi-key constraints or referential integrity.

Isolation: Limited. Operations on individual keys are isolated, but we don't provide transaction isolation levels across multiple keys.

Durability: Yes. Our persistence model allows for tunable durability guarantees with corresponding performance trade-offs.

So while we provide strong guarantees for individual operations, HPKV is not a full ACID-compliant database system. We've optimized for high-performance key-value operations with practical durability assurances rather than complete ACID semantics.

of course. the speeds down to 15us can be achieved over network over our custom protocol on the same region. for sub-microsecond latency, you need to have HPKV running on the same machine as yours :)

sure! :)

yes, in that case data can potentially be lost. 30 sec in a worse case scenario without HA.

sorry for not being clear again. by saying this number does not represent full fsync operation, I meant it doesn't include the SSD write time. this is the time to update KVs internal memory structure + adding to write buffers.

this is fair because we provide transactional guarantee and immediate consistency, regardless of the state of the append-only write buffer entry. during that speed, for a given key, the value might change and a new write buffer entry might be added for the said key before the write buffer had the chance to complete (as you mentioned the actual write on disk is slower) but the conflict resolution still ensures the write of the last valid entry and skips the rest. before this operation HPKV is acting like an in-memory KV store.

thanks for taking time and commenting :) we'd still be happy if you decided to use it and give us your thoughts. as I mentioned in one of the comments below, we're hoping to go open source in future :)

the 600ns figure represents our optimized write path and not a full fsync operation. we achieve it -among other things- through:

1- as mentioned, we are not using any traditional filesystem and we're bypassing several VFS layers.

2- free space management is a combination of two RB trees, providing O(log n) for slice and O(log n + k) - k being the number of adjacent free spaces for merge.

3- majority of the write path employs a lock free design and where needed we're using per cpu write buffers

the transactional guarantees we provide is via:

1- atomic individual operations with retries

2- various conflict resolution strategies (timestamp, etc.)

3- durability through controlled persistence cycles with configurable commit intervals

depending on the plan, we provide persistence guarantee between 30 sec to 5 minutes

thank you :)

the test was done on a single node and a single thread. on multi thread and batch operations, HPKV was still faster on the same machine

that's a great question. the 600ns figure represents our optimized write path and not a full fsync operation. we achieve it -among other things- through:

1- as mentioned, we are not using any traditional filesystem and we're bypassing several VFS layers.

2- free space management is a combination of two RB trees, providing O(log n) for slice and O(log n + k) - k being the number of adjacent free spaces for merge.

3- majority of the write path employs a lock free design and where needed we're using per cpu write buffers

the transactional guarantees we provide is via:

1- atomic individual operations with retries

2- various conflict resolution strategies (timestamp, etc.)

3- durability through controlled persistence cycles with configurable commit intervals

depending on the plan, we provide persistence guarantee between 30 sec to 5 minutes

thanks for taking time to write a feedback :)

That's a false contradistinction: Redis is also disk persisted.

The performance gain mentioned was vs. Redis in memory. so we weren't claiming that Redis can't be persisted (which of course it can), but we were saying that Redis without persistence (which performs faster that with persistence) was still this much slower than HPKV with persistence. But you're correct that we probably should have been more clear in explaining this :)

Did you just benchmarked against only single Redis instance and claimed performance win?

Signle node of Redis vs. Single node of HPKV. so it's an apples to apples comparison

Even if so, how do benchmarks compare against source-available competitor DragonflyDB?

Benchmark with DragonFly coming soon :)

sorry about lack of that information in documentation, we'll update that. for for now, the durability guarantee on Pro is 30 seconds. on Business with HA is 5 minutes.

that's a fair point and you're correct. we will have the SLAs for latency documented and provided soon. in the mean time, please try it out and give us your feedback :)

our approach is actually hybrid. on the other side of the performance coin, we have resource efficiency. that resource efficiency let's us provide a performant and low latency managed KV store, with lower cost, so the economy of it makes sense. the idea is that not everyone requires sub-microsecond latency, and for that group the value proposition is a low latency kv store which is feature rich with a novel bi-directional ws api. for people who need sub-microsecond latency, we're planning custom setup that allows them to make a local vectored interface call to get the sub-microsecond speeds. in between, we have the business plan that provides a custom binary protocol that is the one used in the benchmark :)

correct. however we're actually planning to make the system open source in future; we can't set an exact date as it depends on various factors, but hopefully not too far out. :)