Total cost of ownership reduction
Picodata's shard-per-core architecture lets a cluster handle the same throughput on materially less hardware than shared-memory databases — 2–5× fewer server nodes is a typical observed range.
Why the numbers come out lower
Shared-memory databases (PostgreSQL, MS SQL) hit an architectural ceiling when threads contend on shared resources — buffer pools, locks, caches. Past that ceiling, adding cores yields diminishing throughput, so data-intensive workloads end up over-provisioning servers. Picodata's shared-nothing per-core design has no such ceiling; throughput scales linearly with the core count.
Open benchmark: 1 M RPS message-queue workload
An open benchmark by RT Labs compared PostgreSQL against a shard-per-core database technologically related to Picodata, on a 1 million-requests-per-second message-queue workload. The PostgreSQL-based solution required 4 760 CPU cores at p99 latency 320 ms. Migration to the shard-per-core architecture cut consumption to 770 cores (6× fewer) at p99 latency 130 ms.
Open report «From PostgreSQL to Tarantool» — methodology and measurements (PDF, 5.4 MB) →
Advantages
- Linear horizontal scaling on commodity x86-64 hardware.
- Lower hardware capex and lower operating expenses on the same throughput envelope.
- Open-source core (BSD) — no per-core licensing on the database itself.
See also: migration playbook and commercial services.