11–20 of 47 posts
Earlier quoted context omitted.
SQLite is in process, but concurrent write / performance is a complex matter : https://sqlite.org/wal.html
Yes, that's why I would expect it to smoke Postgres here, in process is orders of magnitude faster. Do you really need concurrency here when you can do 10-100k+ inserts per second?
This is different than 1 user doing the purchase for 100k fans
Is FastAPI just bad with SQLite? I would have expected SQLite to smoke Postgres in terms of ops/s.
----
In our testing:
For batch transactions, Tigerbeetle delivered truly impressive speeds: ~250,000 writes/sec.
For processing transactions one-by-one individually, we found a large slowdown: ~105 writes/sec.
This is much slower than PostgreSQL, which row updates at ~5495 sec. (However, in practice PostgreSQL row updates will be way lower in real world OLTP workloads due to hot fee accounts and aggregate accounts for sub-accounts.)
One way to keep those faster speeds in Tigerbeetle for real-time workloads is microbatching incoming real-time transactions to Tigerbeetle at an interval of every second or lower, to take advantage of Tigerbeetle's blazing fast batch processing speeds. Nonetheless, this remains an important caveat to understand about its speed.
I recently did performance testing of Tigerbeetle for a financial transactions company. The key thing to understand about Tigerbeetle's speed is that it achieves very high speeds through batching transactions. ---- In our testing: For batch transactions, Tigerbeetle delivered truly impressive speeds: ~250,000 writes/sec. For processing transactions one-by-one individually, we found a large slowdown: ~105 writes/sec.…
I recently did performance testing of Tigerbeetle for a financial transactions company. The key thing to understand about Tigerbeetle's speed is that it achieves very high speeds through batching transactions. ---- In our testing: For batch transactions, Tigerbeetle delivered truly impressive speeds: ~250,000 writes/sec. For processing transactions one-by-one individually, we found a large slowdown: ~105 writes/sec.…
I recently did performance testing of Tigerbeetle for a financial transactions company. The key thing to understand about Tigerbeetle's speed is that it achieves very high speeds through batching transactions. ---- In our testing: For batch transactions, Tigerbeetle delivered truly impressive speeds: ~250,000 writes/sec. For processing transactions one-by-one individually, we found a large slowdown: ~105 writes/sec.…
Did the company end up using it?
There was also poor Ruby support for Tigerbeetle at the time, but that has improved recently and there is now a (3rd party) Ruby client: https://github.com/antstorm/tigerbeetle-ruby/
I recently did performance testing of Tigerbeetle for a financial transactions company. The key thing to understand about Tigerbeetle's speed is that it achieves very high speeds through batching transactions. ---- In our testing: For batch transactions, Tigerbeetle delivered truly impressive speeds: ~250,000 writes/sec. For processing transactions one-by-one individually, we found a large slowdown: ~105 writes/sec.…
Doesn't the Tigerbeetle client automatically batch requests?
Earlier quoted context omitted.
Doesn't the Tigerbeetle client automatically batch requests?
We didn't observe any automatic batching when testing Tigerbeetle with their Go client. I think we initiated a new Go client for every new transaction when benchmarking, which is typically how one uses such a client in app code. This follows with our other complaint: it handles so little you will have to roll a lot of custom logic around it to batch realtime transactions quickly.
https://docs.tigerbeetle.com/coding/clients/go/#batching
But nonetheless, it seems weird to test it with singular queries, because Tigerbeetle's whole point is shoving 8,189 items into the DB as fast as possible. So if you populate that buffer with only one item your're throwing away all that space and efficiency.