The Expensify test was targeted at demonstrating the upper limits of SQLite itself. The hardware used:
> 1TB of DDR4 RAM
> 3TB of NVME SSD storage
> 192 physical 2.7GHz cores (384 with hyperthreading)
And a very simple read-only query w/o overlapping rows, with the full dataset already loaded in memory:
> The query itself just sums a range of 10 rows randomly located inside 10B row (447GB) two column database of random integers, one of which is indexed and the other not. This means that the test is fully cached in RAM, and the database is precached prior to the test. No writes are done during this test, only reads.
All that is good and fine for that purpose -- to demonstrate the limits of what SQLite can do in scaling UP.
The purpose of the PlanetScale post was demonstrating linear scalability by scaling OUT using a realistic workload (TPC-C is a warehouse / ecommerce site simulation) on small commodity VMs (ec2 isntances).
As noted, you're comparing two very different tests that had very different goals.
And a very simple read-only query w/o overlapping rows, with the full dataset already loaded in memory: > The query itself just sums a range of 10 rows randomly located inside 10B row (447GB) two column database of random integers, one of which is indexed and the other not. This means that the test is fully cached in RAM, and the database is precached prior to the test. No writes are done during this test, only reads.
All that is good and fine for that purpose -- to demonstrate the limits of what SQLite can do in scaling UP.
The purpose of the PlanetScale post was demonstrating linear scalability by scaling OUT using a realistic workload (TPC-C is a warehouse / ecommerce site simulation) on small commodity VMs (ec2 isntances).
As noted, you're comparing two very different tests that had very different goals.