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 . 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.
-
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. ↩︎