# Native Async/Coroutine Reads in RocksDB

DevFeed: [Native Async/Coroutine Reads in RocksDB](<https://devfeed.tech/articles/native-async-coroutine-reads-in-rocksdb-22403.md>)

Original publisher: [Read original article](<http://rocksdb.org/blog/2026/08/24/native-coroutine-reads.html>)

Author: Josh Kang

Published: 2026-08-24T00:00:00Z

Content type: release

Language: en

Sources: [RocksDB](<https://devfeed.tech/sources/rocksdb.md>)

Topics: [rocksdb](<https://devfeed.tech/topics/rocksdb.md>), [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [IO](<https://devfeed.tech/topics/io.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [async](<https://devfeed.tech/tags/async.md>), [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [blog](<https://devfeed.tech/tags/blog.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [io](<https://devfeed.tech/tags/io.md>), [native](<https://devfeed.tech/tags/native.md>), [rocksdb](<https://devfeed.tech/tags/rocksdb.md>), [thread](<https://devfeed.tech/tags/thread.md>)

## AI overview

RocksDB introduces experimental asynchronous Get and MultiGet APIs backed by native C++ coroutines. The APIs can suspend storage-bound reads, allowing a small executor to run other ready tasks and maintain more storage queue depth without one blocked application thread per read. The feature targets throughput for I/O-bound point lookups rather than reducing individual device-read latency.

## Source excerpt

A point lookup that misses RocksDB's block cache can spend most of its time waiting for storage. The traditional way to keep more reads in flight is to add threads. That works, but each outstanding read parks a thread, carries a stack, and adds context-switching overhead. RocksDB now has experimental asynchronous Get and MultiGet APIs backed by native C++ coroutines. When a read reaches storage, RocksDB can suspend the request, let its read-executor worker run another ready task, and resume the request when the filesystem reports completion. A small executor can therefore maintain more storage queue depth without requiring one blocked application thread per read. These APIs are available in RocksDB 11.10.0. This is primarily a throughput feature for I/O-bound point lookups. It does not make an individual device read faster. Its benefit comes from keeping the device busy and using CPU threads for runnable work. The API surface RocksDB exposes the new read path through two public interfaces: DB::GetAsync and DB::MultiGetAsync return immediately on the native path and report completion through AsyncCallback::OnComplete. CoroDB::CoGet and CoroDB::CoMultiGet return lazy folly::coro::Task objects. CoGet produces a Status; CoMultiGet fills the same per-key values and statuses as synchronous MultiGet. The callback APIs suit applications that do not expose Folly tasks at their boundaries. The CoroDB APIs let coroutine-based callers await RocksDB directly, avoiding an application-side callback-to-Baton adapter and its extra completion handoff. Native execution requires RocksDB to be built with Folly and USE_COROUTINES=1. Neither interface requires ReadOptions::async_io. That flag continues to control the older internal async-I/O optimizations for synchronous MultiGet and iterators. The task APIs are lazy: no read begins until a task is awaited or started. Both interfaces take pointer and reference parameters, so keep the DB, column-family handles, ReadOptions, keys and their