# papaya is a concurrent hashmap that optimises for reads

> papaya is a Rust concurrent hash table with one clear design target, workloads where reads dominate writes. It is mostly lock-free, it exposes atomic operations, it drops into async code without friction, and the part of the design that is unusual is the emphasis on predictable latency rather than on peak throughput, with memory management delegated to a separate crate called seize.

**ibraheemdev/papaya** — A fast and ergonomic concurrent hashmap for read-heavy workloads.

- Repository: https://github.com/ibraheemdev/papaya
- Stars: 955 · Forks: 41
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/ibraheemdev-papaya

## Read-heavy is the whole thesis

The description is short and it states the assumption the library is built around. papaya is a fast and ergonomic concurrent hash-table for read-heavy workloads. The README then spells out what that means in practice, saying that papaya is built with read-heavy workloads in mind, so read operations are extremely high throughput and provide consistent performance that scales with concurrency, and that the library will excel in workloads where reads are more common than writes. It also says the honest thing about the other case, that in write heavy workloads papaya will still provide competitive performance despite not being its primary use case. That is a more useful positioning than a benchmark table, because it tells you which measurements matter when you evaluate it, and it tells you that a write-heavy service is not where this crate wins.

## Mostly lock-free, and honest about the rest

The feature list leads with an ergonomic lock-free API with the note that there are no more deadlocks, and the performance section qualifies it precisely. Most operations are lock-free, and those that are not only block under rare and constrained conditions. That sentence is the one to sit with, because lock-free claims in concurrent collections are usually marketing unless the exception is named. Here the exception is acknowledged rather than hidden, and the consequence for a user is that a blocking operation is possible but rare, which is a different reliability story from a design where any operation can block a thread indefinitely. The deadlock argument also matters, because a map used as a shared cache across a request path is exactly where a lock ordering mistake becomes an outage.

## Predictable latency is the goal, not peak throughput

The README makes a claim that rarely gets made, that papaya aims to provide predictable and consistent latency across all operations, and then it explains why that matters in a way benchmarks do not. It says predictable latency is an important part of performance that does not often show up in benchmarks, but has significant implications for real-world usage. A benchmark reports a mean or a percentile over a synthetic access pattern, whereas a service cares about the tail, the request that takes fifty milliseconds because it collided with a resize. The benchmark files in the repository reflect that priority, with a single thread benchmark and a latency benchmark, both declared with the harness turned off, which is the criterion style, and the development dependencies include an HDR histogram, which is the tool you reach for when you want the distribution rather than the average.

## Atomic operations and async use

Two of the listed features describe how the map is meant to be used rather than how it is built. The first is powerful atomic operations, which is the feature that makes a concurrent map more than a map with internal locking, since a compare and swap or an update-if-present lets you work with the value without holding anything across the call. The second is seamless usage in async contexts, which for a Rust map means the guards and the references it hands out have to be usable inside an async task without blocking the executor, and the fact that it is called out as a feature rather than a footnote says the author has thought about where the map will be held. The topics the repository carries match the same picture, with concurrent, hashmap and hashtable.

## Memory reclamation is somebody else's problem

Efficient memory usage with garbage collection powered by seize is the feature that explains the rest of the design. A concurrent hash table that deletes entries has to reclaim the memory of a removed entry, and doing that safely in the presence of readers that may still hold a reference is the genuinely hard part of the problem. Delegating it to a dedicated crate, seize, means the map does not have to solve safe memory reclamation itself, and the dependency list shows how little else is in the way, with equivalent for key equality, seize with default features off, and an optional serde feature. The feature list in the manifest shows how the trade-off is exposed:

```toml
[features]
default = ["fast-barrier"]
serde = ["dep:serde"]
fast-barrier = ["seize/fast-barrier"]
```

The fast-barrier feature is on by default and forwards to the equivalent feature in seize, so the reclamation strategy is a compile-time choice.

## Resizing without a stop-the-world moment

The performance section mentions that papaya also features incremental resizing, and links to the documentation for the resize mode enumeration. That is a small line in the README and a large deal in practice, because a map that grows has to rehash its contents, and a rehash under a lock is a latency spike that scales with the size of the map. Incremental resizing spreads that work across the life of the table, which is the same idea as the predictable latency claim applied to the one operation that cannot be made constant time. Together with the lock-free read path, it is the reason a read-heavy service can keep its tail latency flat while the map grows underneath it, and it is one of the two or three design decisions that separate this crate from a hashmap with a mutex in it.

## The repository, the tooling and the release state

The tree is small and well organised, with src/ for the implementation, tests/ for the test suite, benches/ for the benchmarks, a fuzz/ directory, an assets/ folder, and a BENCHMARKS.md document at the top level that is the file to read before evaluating the library. The manifest declares the edition as 2021 with a minimum Rust version of 1.72.0, the MIT licence, and categories for algorithms, concurrency and data structures. The development dependencies are the interesting list, with rand for randomised tests, base64, an HDR histogram for the latency measurements, dashmap as a comparison point, criterion for the benchmarks, tokio for the async tests, num_cpus for the threaded ones and serde_json. The lint configuration also shows how the project tests itself, with two custom cfg flags, one for a stress configuration and one for an address sanitizer run, and the check-cfg list tells the compiler to accept them. The releases are 0.2.5 on 2026-08-21, 0.2.4 on 2026-03-29 and 0.2.3 on 2025-06-27, and the last push was on 2026-08-21, so the crate is active and still pre one point zero.

## Conclusion

papaya fits a Rust service whose map is read far more often than it is written, and where a lock on the hot path would show up as tail latency, since the design goal is stated as predictable latency rather than a benchmark number. It does not fit a write-heavy workload, because the documentation is explicit that the read-heavy case is the target even though writes remain competitive. It does not fit a team that wants a crate with a long stable history, because the version is still in the zero series. Before you adopt it, read the benchmarks document rather than the feature list, since the case for this crate is entirely in the measurements, and check the fast-barrier feature, which is on by default and changes how the memory reclamation barrier behaves.

## FAQ

### What is papaya?

It is a Rust concurrent hash table built for read-heavy workloads, offering a mostly lock-free API, atomic operations, seamless use in async contexts, extremely scalable low-latency reads and efficient memory usage with garbage collection powered by the seize crate.

### Is papaya fully lock-free?

No. The documentation says most operations are lock-free and that those which are not only block under rare and constrained conditions, and the feature list notes that the lock-free API means no more deadlocks rather than no blocking at all.

### Why does papaya focus on predictable latency?

Because the authors argue that predictable latency has significant implications for real-world usage and does not often show up in benchmarks. The repository reflects that, with a dedicated latency benchmark and an HDR histogram among the development dependencies, alongside a single thread benchmark.

### What are the main features of the papaya crate?

A fast-barrier feature that is on by default and forwards to seize, an optional serde support, and a minimum Rust version of 1.72.0. The manifest also declares unexpected_cfgs lint allowances for a stress configuration and an address sanitizer run.

### Is papaya still updated?

The repository is not archived and the last push was on 2026-08-21, with 0.2.5 published the same day, 0.2.4 on 2026-03-29 and 0.2.3 on 2025-06-27. The crate is on crates.io and the licence is MIT.

## Sources

- [ibraheemdev/papaya on GitHub](https://github.com/ibraheemdev/papaya)
- [Issues](https://github.com/ibraheemdev/papaya/issues)
- [License: MIT](https://github.com/ibraheemdev/papaya/blob/master/LICENSE)
- [README](https://github.com/ibraheemdev/papaya/blob/master/README.md)
- [Releases](https://github.com/ibraheemdev/papaya/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ibraheemdev-papaya