On this page
A test database is only useful once the rows, keys and indexes are actually in the engine you will query. On 31 October 2026 we timed that moment for a scaled copy of Pagila: 10 million rows, ready in PostgreSQL, in about 52 seconds on a laptop.
The figure is the mean of three runs. Each run created a new database, loaded it, and only then counted every table inside PostgreSQL. No customer data was used.
The number, and the three runs behind it
| Run | Rows counted in the database | Ready |
|---|---|---|
| 10 million, run 1 | 10,000,000 | 54.2 s |
| 10 million, run 2 | 10,000,000 | 50.6 s |
| 10 million, run 3 | 10,000,000 | 51.3 s |
About 52 seconds is that mean. At that pace the load is roughly 190,000 rows per second. The resulting database occupied 1.1 GB in RAM. The profile that drove every run was 233 KB. Nothing was written out as an intermediate SQL file.
We also ran the same shape at 5 million rows, three times. The databases contained 5,000,001 rows and were ready in 25.6 to 25.9 seconds. Doubling the rows roughly doubled the time.
“Ready” here is narrower than a wall-clock feeling. It means the schema, rows, constraints and indexes were in place, and every table’s row count had been read back from the database. The database was dropped after that count. The one-time start of the RAM engine, 3.4 seconds, is not included.
What 10 million rows looked like
The source was Pagila 3.0.0, the familiar PostgreSQL sample of a film-rental shop: customers, inventory, rentals, and payments partitioned by month. It has 22 tables and 36 foreign keys, and about 62,000 rows.
Lyrebird scaled the total about 160 times and kept the ratios between tables. Reference data stayed at source size: film, language, category and country did not inflate with the fact tables. The largest tables in the 10 million row database were rentals and payments at 3.6 million each, film–actor at 1.2 million, and inventory at 1.0 million. Primary keys, foreign keys and indexes were created in the target and enforced by PostgreSQL, not left as comments in a script.
Profile once, then stream into a real engine
Generation did not reconnect to the source. The source was profiled once, on this machine, by the local model on the GPU. That profile step took 18.7 seconds and produced the 233 KB file. Every generate run after that used only the profile.
The target was a real PostgreSQL 16, not a file of INSERT statements. Lyrebird’s RAM engine started it in Docker with a 24 GiB memory budget (lyrebird ram start --ram-mb 24576). That start took 3.4 seconds and was reused. Generate then streamed rows straight into a new database on that engine, with --total-rows 10000000. When the command finished, the database had an ordinary connection string.
Do not credit the GPU for the 52 seconds
The laptop has an NVIDIA RTX 3060 Laptop GPU, and the profile step used it. The generate runs did not get their speed from it. Runs 1 and 2 had the GPU available and finished in 54.2 and 50.6 seconds. Run 3 was CPU only and finished in 51.3 seconds, inside the same range. The end-to-end time is the cost of building the rows and committing them, with keys and indexes, into PostgreSQL.
What this measurement is not
- Hardware. One laptop: Intel Core i7-12700H, 61 GB RAM, RTX 3060 Laptop with 6 GB, Linux. A different CPU, disk or schema will not reproduce 52 seconds.
- Engine. PostgreSQL 16 only. MySQL, SQL Server and Oracle were not part of this run.
- Scope. Time starts at the generate command and stops when the database is ready and the row counts have been checked. It does not include the 18.7 second profile or the 3.4 second engine start.
- Edition. Generation at this scale is part of Lyrebird’s licensed edition. Community is limited to 5,000 rows per table.
- A leaderboard. This is one schema, one scale, one machine. It is evidence that a relational load of this size fits in a minute on a laptop, not a claim about every database.
The practical point is smaller than the headline. A team that already holds a profile can rebuild a 10 million row PostgreSQL, keys included, without copying production and without parking a pile of SQL on disk. The same profile is what Lyrebird generates from after the source connection is gone.
If you want to see the shape of that profile on your own schema, look at Lyrebird or request a demo.