One Person Built an 1.8-Billion-Row Alternative Data Platform in a Year, Revealing Three Major Backtesting Pitfalls

A self-taught veteran spent one year single-handedly building a quantitative research data platform — 764 tables, roughly 1.8 billion rows of data, spanning alternative data, SEC filings, government records, and market data. The core of this project isn't how smart the model is, but whether the data can withstand the scrutiny of backtesting. The author documented every question worth digging into across 206 architecture decision records and 680 research notes.

The Hardcore Architecture of a Quantitative Data Platform

This platform's technical choices are tightly bound to the real needs of quantitative research. The most critical piece is the point-in-time data mechanism: every record is tagged not only with when an event occurred, but also when that information became public, with 103 tables using a bitemporal design (valid time and record time coexisting). This is the core defense against look-ahead bias — the most common form of self-deception in backtesting.

Survivorship bias is handled just as thoroughly. Delisted and renamed companies retain their full history; windows where a stock ceased to exist are scored using delisting returns rather than being simply dropped. The entity resolution layer links records across ticker, CIK, LEI, and CUSIP, and supports point-in-time symbol mapping: tickers get renamed, reused, and delisted, so the answer to "which security does a given company correspond to on a given day" must be answered based on that day's state.

For corporate actions, split and dividend adjustments are verified using independent data sources rather than being self-referential. NLP-based information extraction covers 8-K events, earnings guidance, press releases, IPO prospectuses, SEC comment letters, material contracts, 13D/13G beneficial ownership, insider Forms 3/4/5, and XBRL financials — all converted into structured, dated facts.

The data architecture follows a medallion lakehouse pattern, with Bronze, Silver, and Gold layers built on Parquet, PostgreSQL as the serving layer, roughly 456 data contracts as guardrails, and one-click data lineage to answer "what downstream depends on this table if it changes." The platform also includes MLOps and model validation (feature pipelines, forward-rolling and purged cross-validation, backtesting, and paper trading), plus domain-specific small models and an MCP server that lets AI agents query the data.

All of this runs on a single workstation, with heavy tasks scheduled through a resource broker to keep the machine from devouring itself. Since November 21, 2025, the project has accumulated 4,776 commits and 5,281 Python files, 738 of which are test files.

Look-ahead bias is one of the most destructive errors in quantitative backtesting: the model uses information at time T that was not actually available at time T when making a decision. The classic scenario is earnings data — a company might close its fiscal quarter on March 31, but not file its 10-Q with the SEC until early May. If backtesting simply marks March 31 as the data-available date, the strategy effectively "peeks" at results a month early. The solution is bitemporal modeling: a record carries both a "business valid time" (when the event actually occurred) and a "system record time" (when the information became publicly obtainable), and backtesting is only allowed to query the version whose record time precedes the decision point. This is also why 103 tables need to maintain two sets of timestamps in pairs, rather than simply adding an as_of_date field.

Survivorship bias arises from keeping only the samples that "survived to today." If a database only contains companies currently still listed, the names that were delisted, went bankrupt, or got acquired historically are systematically removed — inflating backtested returns, because those failures are precisely the part that dragged down real returns. The fix is to preserve full history: delisted companies' stock windows are not deleted, but filled at the end with delisting returns, so the strategy genuinely "experiences" that loss during backtesting. Similarly, renamed companies (e.g., Facebook becoming Meta) require entity resolution to link the pre- and post-change tickers as the same entity, otherwise the historical data gets sliced into two disconnected pieces.

The medallion lakehouse architecture divides data into three layers by degree of processing: Bronze holds raw ingested data (uncleaned, preserving the vendor's original form), Silver handles cleaning, deduplication, standardization, and entity resolution, and Gold produces aggregate or feature tables for specific business scenarios. This layering lets errors be traced back to their source and allows different teams to consume data independently at different layers. Combined with data contracts — explicit agreements about table structure, field types, value domains, and freshness — upstream changes must be announced to downstream consumers beforehand, avoiding silent failures where "the producer changed a field's meaning and the consumer never noticed." 456 contracts mean that nearly every externally exposed table has an explicit interface commitment.

Three Data Quality Lessons

The pitfalls the author hit during the build are more valuable than any technical warning.

Labels Lie; Specs Don't

SEC fund holdings data (Form N-PORT) has a field called "Ticker." Measuring across all quarters the SEC has published, about 28% of roughly 17.4 million values are not stock tickers — mortgage pool codes, bond issuer symbols, and futures contract codes are mixed in. A pool code FG is also an NYSE ticker, and a naive join would turn a Freddie Mac mortgage pool into an insurance company's stock.

The fix isn't smarter code — it's metadata management. The SEC's own form instructions state that this field is a fallback identifier. The author now builds a data dictionary from official documentation before processing any institutional data. The first seven dictionaries alone surfaced 12 defects in the SEC's own published files.

N-PORT is the holdings disclosure form (Form N-PORT) that the SEC has required registered funds to file quarterly since 2019, replacing the earlier N-Q. It contains information on each fund holding's identifier, quantity, valuation, and derivatives exposure, making it an important primary source for studying institutional capital flows. But N-PORT's field design reserves a large set of "fallback" identifiers: when a holding isn't common stock, the filer may put a CUSIP, a mortgage pool code, or a derivatives symbol in the Ticker field. This explains why 28% of values aren't stock codes — it's not a data error, but a broad semantic permitted by the spec that downstream consumers misread as "this is a ticker." This is also the direct motivation behind the author's emphasis on "read the official form instructions first, then parse."

Tests That Compare Data to Itself Prove Nothing

One night, all price data quality checks passed. The next morning, independent reconciliation found that 236 days of prices had been rewritten to the wrong side of a split. Every check was comparing the pipeline against its own output. Now, data quality claims require an external witness.

Coverage Is Not Precision

In entity resolution, the easy metric to measure is match rate, but the useful metric is precision. A shortcut that raised match rate by ten percentage points was only 38% accurate against independent identifiers. It was never shipped.

Tools Already Open-Sourced

There are currently two open-source releases. split-adjustment-tool is a vendor-neutral Python tool (built on Polars) for validating, fixing, and applying split adjustments, under Apache 2.0, version 0.4.0. us-gov-data-dictionary provides machine-readable data dictionaries for seven SEC datasets, covering 1,469 fields, each with the SEC's own definition and citations, official code tables, and profiles of the actual contents of published files, in W3C CSVW and SKOS formats, under CC BY 4.0.

More agencies will be covered in the future. What the author most wants to hear is this: if you've ever been quietly deceived by data while working with public financial data, that story is worth sharing.

One-line Summary

A veteran spent a year single-handedly building a point-in-time quantitative data platform with 764 tables and 1.8 billion rows, and distilled three data quality lessons.

Paragraph Summary

This article describes how a self-taught developer spent one year building a quantitative research data platform alone on a single workstation. The platform contains 764 tables and roughly 1.8 billion rows spanning alternative data, SEC filings, government records, and market data, with a core design of bitemporal point-in-time data (103 tables) and survivorship bias handling to combat look-ahead bias in backtesting. The author distilled methodology across 206 architecture decision records and 680 research notes, and summarized three data quality lessons: field labels can't be trusted — defer to official specs; self-referential tests can't catch systemic errors — external reconciliation is mandatory; and entity resolution should look at precision, not match rate. The project has open-sourced a split adjustment tool and seven SEC data dictionaries.