Performance

Fast Performance

TwiceDB is regularly benchmarked for performance. Since the ecosystem for testing bitemporal databases is not yet as rich as that of traditional OLTP databases, we cannot use standard tools like TPC-C TwiceDB . Instead, our client libraries ship with simple performance test examples. The results displayed below were obtained by running the Go client performance example.

All tests use c7g.xlarge instances with gp3 disks (3000 IOPS) in us-east-1b.

Single server, single client

For this test, we write n (n = 1000) brand new objects to a single TwiceDB server using a single client. Then, we read all n of those objects back in a single query. Finally, we read all n of those objects back one-by-one, first by unique key, then by objectId. We run this test 10 times after a warmup period of 3 runs using the performance example distributed with the Go client library. Objects / sec timings are from the client’s perspective.

Metric One-by-one Batch1
Point reads (throughput) >2,650 objects / sec >7,150 objects / sec
Point reads (latency, p99) <1ms <20ms
Writes (throughput) >90 objects / sec >200 objects / sec
Writes (latency, p99) <300ms <600ms

Single server, multiple clients

This test is the same as the single client test, but with c (c = 8) clients running simultaneously. Metrics are shown per-client, not from the perspective of the database.

Metric One-by-one Batch1
Point reads (throughput) >1,000 objects / sec >1,300 objects / sec
Point reads (latency, p99) <10ms <200ms
Writes (throughput) >20 objects / sec >30 objects / sec
Writes (latency, p99) <1,900ms <3,500ms

Horizontal scaling

All TwiceDB servers act as one of a writer, a reader, or both. Readers may be scaled horizontally with no known limit.


  1. TwiceDB is optimized for batch processing to read or write multiple objects in few client-server round-trips. Unless you need to use the synchronous read and write methods, the async methods are preferred. ↩︎

Copyright © 2024 TwiceDB TwiceDB