Home

Awesome

WASI Key-Value Store

A proposed WebAssembly System Interface API.

Current Phase

WASI Key-Value is currently in Phase 2.

Champions

Portability Criteria

wasi:keyvalue must have at least two implementations in terms of relevant mainstream key-value stores in each of the following categories:

  1. Open-source key-value stores like Redis, Memcached, Etcd etc.
  2. Proprietary key-value stores like AWS DynamoDB, Azure CosmosDB, Google Cloud Firestore etc.

The implementations must be able to run on Linux, MacOS, and Windows.

A testsuite that passes on the platforms and implementations mentioned above.

Table of Contents

Introduction

This wasi:keyvalue proposal defines a collection of interfaces for interacting with key-value stores. It additionally defines a world, wasi:keyvalue/imports, that groups together common interfaces including

  1. Store operations on single key-value pairs
  2. Atomic operations on single key-value pairs
  3. Batch operations on multiple key-value pairs

There is also an additional world called wasi:keyvalue/handle-watch, which includes the full imports world as well as a set of interfaces for watching for changes to a key-value store.

The API is designed to hide data-plane differences between different key-value stores. The control-plane behavior/functionality (e.g., including cluster management, data consistency, replication, and sharding) are not specified, and are provider specific.

Goals

The primary goal of this API is to allow WASI programs to access a wide variety of key-value stores. This means the wasi:keyvalue interfaces should be implementable by a wide variety of key-value stores, including but not limited to: in-memory key-value stores, on-disk key-value stores, document databases, relational databases, and either single-node or distributed key-value stores.

The second goal of wasi:keyvalue interfaces is to abstract away the network stack, allowing applications that need to access key-value stores to not worry about what network protocol is used to access the key-value store.

A third design goal of wasi:keyvalue interfaces is to allow performance optimizations without compromising the portability of the API. This includes minimizing the number of copies of data, minimizing the number of requests and round-trips, and support for asynchronous operations.

Non-goals

API walk-through

The proposal can be understood by first reading the comments of world.wit, store.wit, atomic.wit, and batch.wit.

Working with the WIT

Bindings can be generated from the wit directory via:

wit-bindgen c wit/ --world imports

and can be validated and otherwise manipulated via:

wasm-tools component wit wit/ ...

References & acknowledgements

This proposal was inspired by Dapr's [State API]

State API

Change log