Open-source PostgreSQL-compatible SQL with shard-per-core scale. The same plugin model already speaks Redis and Cassandra wire protocols.
Already using Redis or Cassandra? Migration playbook →
Picodata is a distributed SQL database with a shard-per-core architecture. Each process owns its scheduler, memory, files, and write-ahead log — no contention with neighbors. Two optimizers handle queries: a distributed planner for cluster-wide SQL, a local engine for single-node work. Plugins add wire compatibility for Redis, Cassandra, and PostgreSQL.
Each Picodata process runs on a single CPU core and owns its data shard. Replication and sharding work together: processes form master + replica groups, and sharding splits the dataset across those groups, one slice per group. Writes hit a local write-ahead log; replication can stay inside one data center or span several.
Picodata gives you placement control over SQL data. Related rows — a customer and all their orders — live on the same node. Global lookup tables, like the list of stores, replicate everywhere. SQL moves less across the network and runs more in parallel — for OLAP and OLTP alike. The distributed planner splits each query into local blocks, then compiles each block to per-node bytecode.
The Picodata core is open-source. Rust plugins run against the shared SQL catalog and extend the engine in place. The Picodata team ships four commercial plugins as proof of the model: Radix (Redis protocol), Sirin (Cassandra CQL), Ouroboros (cross-cluster async replication, like Oracle GoldenGate), and Franz (Kafka reader). The SDK is open — write your own.
Picodata is not a universal database. The matrix below shows where it fits — and where it doesn't.
| Situation | Picodata | PostgreSQL | Cassandra | Redis |
|---|---|---|---|---|
| Standard CRUD up to 10 TB, local transactions | Overkill* | Optimal | Bad fit | Bad fit |
| Bulk time-series writes (IIoT, telemetry) | Works (via Sirin) | Bad fit | Optimal | Bad fit |
| Hot-data cache (key-value without ACID) | Works (via Radix) | Overkill | Bad fit | Optimal |
| High-throughput queues, session store, real-time OLTP | Optimal | Works (up to ~10K RPS) | Works | Works |
| Distributed in-memory analytical SQL | Optimal | Bad fit | Bad fit | Bad fit |
| Sharded ACID transactions across many nodes | Optimal | Works (with Citus / 2PC overhead) | Bad fit | Bad fit |
* Picodata does not replace general-purpose databases. On workloads that fit a single server, shared-memory engines like PostgreSQL are more efficient and easier to run than a sharded cluster — network coordination has cost that doesn't pay off below a certain scale.
The Picodata core is open-source. Three ways to start: download a build, read the docs, or browse the source.
Builds for RHEL, Debian, Ubuntu, Fedora, Alpine, and a Docker image. BSD licensed.
Download →Architecture, install, SQL reference, plugin model, migration paths.
Open the docs →Public GitLab repository. Star it, file issues, send merge requests, build your own plugins on the open SDK.
Go to the repo →