How Much Tabular Data Do You Need? Rows, Cells, Tables and Time Span

Rows are the wrong budgeting unit for structured data

Row count misleads because rows are neither independent nor equally informative. A 50-million-row order_lines table may describe 40,000 customers, 3,000 SKUs and 600 returns, and a churn or fraud model learns from the 600, not the 50 million. Wide tables also hide volume: 1 million rows by 12 columns and 1 million rows by 400 columns are different purchases.

Translate every request into five units before pricing or scoping: cells (rows times populated columns), distinct tables or schemas, distinct entities (customers, accounts, assets, SKUs), labeled positive cases for the target, and calendar span of history. Power-law learning curves have been measured across several deep learning domains [7], and the same pattern is a reasonable planning assumption here, so each doubling of the binding unit buys a smaller gain than the last. The point of a sizing exercise is to find which unit binds first. The data volume estimator is a quick starting point; the rest of this page explains the units.

Tabular foundation model pretraining is sized in cells and table diversity

For pretraining a tabular foundation model, the working unit is cells drawn from many distinct tables, not rows from one large table. TabDPT reports that performance on held-out tabular benchmarks keeps improving as real pretraining data grows, with power-law gains measured from roughly 52 million to 2 billion cells [1]. That range is a useful order-of-magnitude anchor for a buyer: a few hundred million cells is a meaningful real-data contribution, and billions of cells is research-lab scale.

Table count matters as much as cell count. A model that predicts in context across arbitrary schemas needs exposure to many column semantics, target types, class balances and missingness patterns; a billion cells from one CRM export teaches one schema very thoroughly. The original TabPFN was pretrained only on synthetic tables generated from structural causal models, and Real-TabPFN added a continued-pretraining stage on real-world tables to close the gap [2]. That pattern suggests real enterprise tables are most valuable as a diverse, curated layer on top of synthetic priors rather than as raw bulk.

For a pretraining purchase, specify a target in cells, a minimum number of distinct source tables, caps on cells per table (so no single extract dominates), and a held-out set of tables that never enters pretraining. The tabular foundation model pretraining guide covers the data mix in detail.

Time-series volume is series, time points and frequencies, plus enough history

Forecasting data is sized on three axes: number of distinct series, total time points, and the spread of frequencies and domains. Work on neural scaling laws for time-series foundation models ties forecasting performance to the volume of pretraining data in a predictable way [3]. For scale, the GIFT-Eval benchmark alone spans 23 datasets, about 144,000 series and 177 million data points across seven domains and 10 frequencies [4], and that is an evaluation suite, not a pretraining corpus.

History length is a separate constraint that volume cannot replace. As a working rule (a hypothesis, not a published minimum), a series should cover at least two full cycles of its longest seasonality plus the forecast horizon plus a backtest window. A weekly retail series with annual seasonality, a 13-week horizon and four rolling backtest origins needs roughly two years plus about six months; buying 10,000 more stores with 14 months each does not fix a model that never sees two Christmases.

Also record the covariates the model will use at inference time, such as price, promotion flags and holiday calendars, because a series without its drivers is cheaper and less useful. See time series with covariates and time-series foundation model training data.

Task models are bounded by positive cases and distinct entities

For a supervised model on one business problem, the binding unit is usually the count of positive cases and the count of distinct entities, not total rows. Fraud, chargebacks, equipment failures, contract disputes and churn are rare events, so a table with millions of rows can carry only hundreds of positives. Our working hypothesis: budget for enough positives to fill a stratified validation set and a test set (several hundred each is a common floor for stable precision and recall estimates) and then add training positives until the learning curve flattens.

Task-specific scale can be modest. One applied entity-resolution study caps training and validation at 10,000 records each across six deduplication benchmarks [5]; that is a design choice, not a proven minimum, but it shows the order of magnitude task models work at. What matters more is composition: the WDC Products benchmark varies the share of hard corner cases and of entities unseen in training, alongside development set size [6]. A small set rich in near-duplicates and unseen entities tests more than a large set of easy pairs. See entity resolution training data.

Count distinct entities because splits must be by entity. If 2 million transactions come from 8,000 accounts, you have 8,000 independent units for a grouped split, and leakage across that split will inflate every metric. The target leakage audit and point-in-time correct training data pages cover the checks.

Relational and multi-table data is sized by keys and joins, not by the largest table

A relational dataset is sized by the entities at the root of the task and by how many related tables survive the join, not by the row count of the biggest fact table. A relational deep learning task on customers, orders, order_lines, returns and support_tickets is only as large as the number of customers with complete, key-consistent history across those tables.

Sampling a relational extract by rows breaks foreign keys and silently drops children; sample by root entity and pull all descendants. Specify which tables are required, the join keys, the referential-integrity rate you will accept (for example, the share of order_lines.order_id values that resolve to orders), and the snapshot or as-of logic. See multi-table relational data and sampling relational extracts.

Evaluation data is sized separately and often costs more per unit

Evaluation sets need fewer records but stricter properties: held out by entity and by time, never seen in any pretraining or fine-tuning stage, and stratified so rare classes have enough cases for confidence intervals. For forecasting, a held-out set should include series and periods outside any public corpus a vendor model may have trained on, which is why benchmark builders worry about non-leaking pretraining data [4].

Budget the evaluation set first, because it fixes the minimum positive count and history window the training purchase must exceed. ISO/IEC 5259-4 frames data quality as a process across training and evaluation data [8], which is a useful structure for writing acceptance checks into the purchase. See held-out forecasting evaluation data.

Sizing worksheet for a structured-data purchase

Use this sheet to turn a model goal into a request. Fill the binding unit first; everything else follows from it.

Illustrative example: invented to show structure; it does not describe an available dataset.

Read the implied rows last. In both examples the row count is a consequence of the binding unit, which is why two purchases with similar cell counts can serve completely different goals.

Common sizing failure modes

Most structured-data purchases fail on composition, not volume. The recurring problems are:

• Positives that collapse after deduplication. Dispute or fraud flags duplicated across status-change rows look like thousands of positives and turn out to be hundreds of events.
• History truncated at a system migration. An ERP cutover (for example, a move to a new ledger) often leaves earlier years in a different schema; check that posting_date coverage is continuous. See ERP data for AI training.
• One dominant source table. A pretraining mix where one export contributes most cells under-delivers on schema diversity [1].
• Labels that need a lag. Outcomes such as churn or default require a maturation window; the last months of an extract may be unlabeled.
• De-identification that removes the grouping key. If account numbers are replaced inconsistently, grouped splits become impossible; ask for consistent pseudonymous keys. See de-identifying tabular data.

For cross-modality context, compare the sizing logic in how much training data to buy and the supplier-side view in how many records AI labs want and minimum dataset size buyers accept. The structured data buyer's guide and the AI data hub cover the wider category.

Where SourceX fits in a structured-data purchase

SourceX sources operational datasets from US companies, including support and sales histories, engineering records, and finance and legal workflows, on request rather than from stock, so a well-sized request is the starting point. Buyers describe the data they need (the binding unit, tables, history window and held-out rules above), and SourceX looks for US businesses that hold it; a request does not guarantee a match, and every release is approved by the supplying company. You can describe your structured-data requirement to SourceX.

Each dataset is rights-reviewed for ownership and consents, personal details such as names, emails, phones and account numbers are removed or replaced before delivery with the method recorded, and delivery follows an executed license that defines records, uses, term and delivery.

Request tables, entities and history for your model

Start from your binding unit and write the worksheet above before you talk to any supplier. SourceX runs Find, Assess, Agree, Transact and Manage for operational datasets from US companies, and nothing is contracted until a supplier agrees. Describe the tables and history you need.