Originally published at pokerhack.org
Introduction and Definition
Hand history databases are structured repositories of every action, event, and outcome generated during poker sessions. In practical terms, they are the centralized logs that enable quantitative analysis of play patterns, sizing distributions, and decision points across thousands or millions of hands. This article defines how to design, populate, and query such databases to extract actionable insights while acknowledging the regulatory and methodological constraints that accompany data collection in online platforms.
In verified environments, hand histories capture preflop actions, pot stakes, street-by-street betting, and final results with timestamps and player identifiers. For researchers and professional players, the value lies in translating these streams into descriptive and predictive signals—showing how players tend to bet in pressure situations, how table dynamics shift with stack depth, and how line-by-line decisions cohere with overarching strategy. The core challenge is to move from raw logs to robust models that generalize beyond a single session or platform.
From a methodological perspective, database analysis in poker sits at the intersection of data engineering, statistics, and game theory. It requires careful schema design, efficient extraction pipelines, and rigorous validation to avoid spurious correlations. This article proceeds with a focus on practical architecture, reproducible workflows, and concrete examples that seasoned practitioners can port to their own research environments.
Core Content — Section 1: Data Architecture and Schema Design
The backbone of effective poker data analysis is a well-structured schema that captures all relevant dimensions of a hand without redundancy. A canonical design typically includes: (1) a Hands table with hand_id, start_time, platform, table_id, stakes, game_type, and final_result; (2) a Streets table with street_id, hand_id, street_name, pot_pre, street_action, action_type, and player_id; (3) Actions table detailing every decision (player_id, action, amount, timestamp, stack_before/after); (4) Players table with player_id, screen_name, reputation score, and demographic proxies where permitted; (5) Cards table for known hole cards, board cards, and runouts (masked where privacy applies); (6) Known equity proxies and metadata such as position, line of play, and bet sizing patterns. Structurally, denormalized views can speed analytics, but normalization protects consistency. The design should support time-based queries, session stitching, and cross-table joins for comprehensive context.
In practice, use columnar storage (e.g., Parquet) for analytic workloads, and consider event-sourced designs where each action is a discrete event with finite state transitions. Partition by date, game type, or platform to optimize scan performance. Data quality controls are essential: enforce valid timestamps, guard against missing action fields, and implement identity resolution to avoid duplicate hand records across data ingestion pipelines.
For data provenance and reproducibility, maintain a lineage log that records data source versions, parsing rules, and ETL job identifiers. This is particularly important when platform policies change, or when you backfill historical data from older APIs. The architecture should also accommodate privacy and compliance considerations by masking or aggregating sensitive fields where required by policy or law.
Core Content — Section 2: Extraction Techniques and Feature Engineering
Extraction begins with parsing raw hand histories into the canonical schema. This involves robust parsers that handle diverse notations (tournament vs. cash games, multiple currencies, and platform-specific shorthand). Once parsed, feature engineering transforms events into informative signals: adopting strategy-aligned features such as: preflop raising ranges by position, three-bet frequencies by stack depth, continuation bet (c-bet) frequency and size by board texture, and showdown value vs. bluff indicators. Feature categories typically include: (a) action-level features (bet sizes, frequencies, actions per street), (b) player-level features (aggro factor, bet sizing tendencies, adaptation over session), and (c) situational features (position, stack-to-pot ratio, table dynamics).
Statistical reliability hinges on sample size and controlling for non-stationarity. Use rolling windows, hierarchical models, and stratified sampling by position and table type to reduce selection bias. Regularization and cross-validation guard against overfitting to idiosyncratic players or single sessions. Visualization of distributions—such as bet-size histograms by street or heatmaps of raise frequencies by position—offers immediate diagnostic value.
Advanced users implement event-level modeling with logit/probit frameworks for decision outcomes (e.g., fold vs. call vs. raise) and survival analysis to study stack dynamics an
Read the full analysis: Database Analysis in Poker: Extracting Insights from Hand Histories (Advanced Tech)
Top comments (0)