What this means

• Up to a few hundred thousand records per dataset, everything stays interactive. Pages, publishing, checks and copies take well under two seconds at 500,000 records.
• Record history is prepared once after a large dataset is created or imported: about 3 seconds per 100,000 records. A background job does it within about 15 seconds of the change. If someone opens the dataset's record history or approval marks before the job finishes, they wait for it once. After that, each version adds a fraction of a second.
• Whole-dataset work is cached per version. Issues, health, validity history and the grid's view of the records are computed once per published version, and served from memory until the next one.
• Memory: each app process keeps the latest version of each dataset it serves in memory, plus up to 32 earlier versions it has read recently. Plan for about 40 MB per 500,000 records of ten fields, per version held.
• dbt seeds are meant for small reference tables. Datasets over the configured limit (10,000 records by default) are left out of the dbt project; read their Delta table instead (catalog registration gives it a name).
• Published copies in Parquet or CSV are rewritten whole on every version. That's fast at these sizes, but for millions of records, choose Delta copies (one commit per version) or read the dataset's own Delta table.