Historical Matka Data: Analyzing 10 Years of Trends

Ten years of Matka data is not a bigger chart. It is a different object. A three-month chart asks what happened. A ten-year chart asks what happened under a set of rules that no longer exist, on a calendar that was edited by hand, in a database whose own configuration deletes the history it is being advertised for. This page takes the decade claim seriously and follows it into the machinery: the retention row that caps how far back anything goes, the three mutually inconsistent definitions of "a day that happened", the weekly calendar that has no effective dates, and the arithmetic of what a single year of a single market can actually detect - which is the number nobody quotes when they show you ten bars.

What "Ten Years of Trends" Is Claiming

A title like Analyzing 10 Years of Trends makes four claims at once, and each one is checkable separately. It claims a span: ten years of dates exist. It claims a unit: those dates carry declared results, not gaps. It claims comparability: a 2018 draw and a 2026 draw are the same kind of event, so a line connecting their statistics means something. And it claims a signal: something in that span differs from what pure chance would produce, and the difference is large enough for the sample to see.

Most writing about historical Matka data argues about the fourth claim and never touches the first three. That is a mistake, because the first three are where decades actually die - and they are not opinion questions. They are rows in a configuration table, a WHERE clause and a scheduled job.

The rest of this page works through those four in order, because the order matters. A ten-year analysis of a system that retains 181 days is not a weak analysis; it is a category error, and the statistics cannot rescue it.

The Ceiling Nobody Tells You: A Row in a Configuration Table

Every product that publishes Matka history has a retention policy, because every product has a database that grows. In this one the policy is not folklore or an ops habit - it is a table, seeded by migration V48__database_cleanup_system.sql, and it is readable. Twenty rows are seeded there; a twenty-first is registered later by V75__production_data_archiving_system.sql. All of them ship enabled.

The row that matters for a decade is this one, verbatim from the seed data:

market_days is the table the charts are drawn from: one row per market per date, holding the open and close results. The cleanup function is told to compare its date column - the trading date, not the insertion timestamp - and to delete anything strictly older than CURRENT_DATE - 180. Counted the way the pages count, inclusively, that leaves 181 dates.

The Schedule, Because "When" Changes How Much Goes

The job is not a manual habit either. It is @Scheduled(cron = "0 30 3 * * *", zone = "Asia/Kolkata") - 03:30 IST every day, after the last market closes, with a guard that refuses to run between 10:00 and 24:00 IST and a thirty-minute execution budget baked into the configuration defaults. Inside the database function, each table's delete runs in batches with a five-minute abort and a 0.1-second pause between batches. At 03:30 the orchestrator walks cleanup_config ordered by retention_days ASC, so the shortest-lived tables are purged first.

In steady state that is a very small number of rows and a very large number of mornings. The chart table holds 25 MAIN markets, so the purged set is 25 rows every morning - one per market, one day older each time - which is 9,125 rows a year, and 27,425 across the deepest window any page here asks for. The hourly side contributes 13 settled results a day, 4,745 a year. Nothing dramatic happens on any given day. That is exactly why a decade disappears without anyone noticing: the deletion is smaller than the noise floor of an operations review, and it is identical every day, so no incident is ever declared.

Three Definitions of "a Day That Happened"

Suppose the retention problem were solved. The next question a decade must answer is what a row means, and this schema answers it three different ways in three different places - none of which agree with each other, which is worse than any single one of them being wrong.

Read the consequences of the first one carefully, because it inverts the usual fear. The status enum has seven states: NONE, PENDING, OPEN_SAVED, CLOSE_SAVED, OPEN_DECLARED, CLOSE_DECLARED, FULL_DECLARED. The purge targets one of them. So:

• Every complete trading day is deleted after 180 days.
• Every incomplete day - half-declared, pending, never declared - is permanent, and accumulates forever.

That is the opposite of an archive. Six of seven statuses are immortal; the one that represents "this market finished" is the one with an expiry date. A decade built on this table would not be a decade of results with some holes in it; it would be a decade of holes with the results removed, and the surviving rows would be exactly the days that failed to complete.

The second definition then re-admits those half-days into the chart: the feed's predicate accepts a day whose close session is empty, so an "OR" appears where a decade of comparability needs an "AND". The third is subtler and is the one that quietly invents data. getOrCreateMarketDay appears in five call paths in the service, and its own documentation says the row is created lazily on first API request. Nobody pre-creates a calendar. A trading day that nobody opened a page for may have no row at all; a day that was cancelled but requested has one. Absence of a row therefore does not mean "the market did not run", and presence does not mean "a result exists". The chart you read has been partly authored by which pages which readers visited.

This is the mechanism behind the failure mode the missing-dates analysis works through from the reader's side: a gap that is structurally indistinguishable from a cancellation. Here you can see where the gap is manufactured.

Which Ten Years? The Window Is a Choice You Inherit

"Historical data" always arrives inside a window, and in this product the window is set by whichever page you are on. The anchors below are computed the way the code computes them - LocalDate.now(IST) minus an expression, both ends inclusive - against the date this audit was run, 2026-10-28, and they walk forward with today's date every day they are re-read.

Three numbers fall out of that table. The deepest window any code path in this repository asks for is 1,097 dates - and note the emphasis, because it is load-bearing: no query, endpoint or template in 306 source files requests a period longer than three years. The decade is 3.33 times wider than the widest thing the software does. And retention is 20.18 times narrower than the decade, which means the configured purge deletes 95.05% of the span the title names.

Inclusive Counting Is Not a Pedantic Point Here

Every window above is one larger than the subtraction suggests, because date >= start keeps the start date. A 730-day filter returns 731 dates. That single-date offset is invisible at three years and becomes a cliff at year boundaries: the smallest retention setting that can contain even one full calendar year is 365, because 365 keeps 366 dates. At 180 - the shipped value - the number of complete calendar years this database can hold is zero. Not "one, roughly". Zero, by construction: no 180-day window contains a January through December.

So a "yearly pattern" chart, drawn from this system, cannot be a chart of years. It can only be a chart of rolling halves of years, relabelled.

Two Analysts, One Phrase, Different Decades

Even with unlimited retention, "the last ten years" is not one window. Against this anchor date, a trailing decade spans 2016-10-28 to 2026-10-28 - 3,653 dates - while the calendar decade 2016-01-01 to 2025-12-31 spans 3,653 dates too, but shares only 3,352 of them: 91.8%. The calendar version starts 301 dates earlier and stops 301 dates later. Same phrase, same length, 301 days of disagreement.

At one year the disagreement is far worse, and one-year comparisons are what "trend" charts actually get built from. A trailing year from today covers 366 dates; calendar 2025 covers 365. They share 65 dates - 17.8% of the trailing window. Two people who both honestly say "the last one year" and mean the two natural readings are analysing series that overlap by about a fifth and disagree on 301 dates. Before any statistics at all, that is the reason two Matka yearly charts can both be correct and look nothing alike. The page that separates result time, update time and archive date covers the third layer of the same problem: even a date you can see on screen is not necessarily the date the row means.

The Calendar Is a Setting, Not a Record

A decade of daily data is only a decade if you know which days were supposed to happen. Here is that subsystem, entire: a table created by V46__market_weekday_settings.sql with columns id, market_id, weekday, is_open, created_at, updated_at, and a uniqueness rule on (market, weekday). The migration comment states the default direction, and it is the one that bites:

Now do the arithmetic that makes this matter. Over the 3,653 dates of a decade, each weekday occurs 521 or 522 times - the spread is exactly one, because 3,653 = 521 weeks and 6 days. A market that closes one fixed weekday therefore contributes 3,131 to 3,132 trading dates, 85.7% of the span. That is a real, honest, useful number: it is the denominator every frequency table for that market should divide by, and it is precisely what the weekly-off-day analysis argues readers rarely get.

But hold that against the calendar's lack of effective dates, and the number stops being a fact about history. A weekday close applied in 2021 and lifted in 2023 leaves no trace in the settings table - the row reads "open" today, full stop. The audit row that recorded both edits is deleted after 15 days. So the 3,131 figure can be computed for today's calendar and for no other date in the decade, which means the denominator a decade-long analysis needs is exactly the quantity the system cannot reconstruct.

And the Grid Does Not Line Up With Years Anyway

Even a perfectly documented calendar would not make yearly slices comparable, because the chart is a Monday-to-Sunday grid and the year is not. For the three-year window, 1,097 dates render as 158 week rows and 1,106 cells: five structural blanks before the first date, four after the last, nine in total. A decade of dates would need 523 week rows and 3,661 cells.

Because 365 mod 7 is 1 and 366 mod 7 is 2, a fixed calendar date moves one weekday per common year and two per leap year; across the ten years to this anchor the drift is 13 days, or six weekday steps. Two February 29ths fall inside the trailing decade. So "the Tuesday column of 2019" and "the Tuesday column of 2024" are not the same set of dates, and a visual pattern that appears to repeat down a column of a year-by-weekday chart is partly the calendar slipping against the grid. The cross-market chart comparison shows how differently markets lay out for exactly this reason.

Regime Change: What a Decade Series Silently Crosses

Comparability is the claim most often broken and the one least often checked, because nothing announces the break. In this schema the mechanisms are concrete, and all of them are permitted by design.

None of these are bugs. A product that survives ten years must be able to rename a market, close a weekday, and change a rate. The point is narrower and harder: a system that permits regime change without versioning it cannot support a regime-spanning comparison, and a decade of charts drawn across seven unrecorded regime changes is a single series only in appearance. Each of the four claims in the opening table dies here - not because the data vanished, but because the meaning of "the same measurement" quietly moved.

The one defence available to a reader is provenance per row, and it is thin. The declaration timestamps are real (open_declared_at, close_declared_at), and result_status is derived from them by V8. But MarketDay has a non-updatable createdAt and no updatedAt, and no correction-history table exists: a search of all 306 source files, every template and all 90 migrations returns zero occurrences of a CREATE TABLE ... history, zero result-snapshot tables, zero effective-dated configuration columns and zero materialized views. What a public chart cell asserts about the past rests on the value sitting in the column right now. What a result screenshot cannot prove is the reader-side version of that sentence, and the correction-policy page is what an honest product would publish instead.

How Much of a Decade This Database Can Hold

Put the span, the catalogue and the retention in one place and the arithmetic is short enough to quote at any vendor making a decade claim.

The last row is worth staring at. The chart page asks for 1,106 cells of history and the retention row permits 181 dates: the page is built to display six times more than the system is configured to keep. Of the 1,097 dates the three-year window itself asks for, 916 cannot carry a declared result - not because the market failed to run, but because whatever recorded it was deleted at 03:30 on a morning nobody was watching. That is not a bug in the page - the page is written against a policy that would have to be changed deliberately, and the mismatch is the visible scar of that decision being deferred. The mechanism that fills those absent cells - the placeholder that appears where a declared number does not exist - is documented in why the chart shows stars.

There is also a specific asymmetry here that makes the decade claim sharper rather than softer, and it is worth naming because it is unusual: the product does have an archiving system. V75__production_data_archiving_system.sql creates bets_archive and wallet_transactions_archive, redefines the cleanup function so those two tables are copied before they are deleted, and rebuilds the passbook view to union live and archived rows. Money history is preserved indefinitely. market_days is not in the archive branch. It falls to the ELSE path: plain delete, no copy. The ledger of what you bet survives every decade; the ledger of what was drawn does not. For an analyst that is a perverse inversion - the money records reference market_day_id values that no longer exist, so a decade of your own betting history becomes joinable to nothing.

What One Year of One Market Can See

Assume, generously, that someone has archived ten years of declared results outside the product. The fourth claim - that a yearly trend is visible - then depends entirely on how many observations a year contains. The unit here is the ank digit: one declared session gives one last digit, and each market_days row carries two embedded result slots, openResult and closeResult, so a market-year of 313 trading dates is 626 digits and a market-decade is 6,262.

Against a fair ten-way digit (each digit 10% of the time), these are the noise baselines - simulated, not asserted, at 400,000 trials per row with a seeded generator and re-run with the platform random source as a cross-check:

Two readings. First: a ten-way digit is more than 10% "hot" almost whenever you look - about a quarter of the time at annual scale, and never less than a fifth even with 156,550 observations. The probability barely moves as the sample grows ten-fold, which is the tell: this is not a signal being diluted, it is a property of taking a maximum over ten cells. The cross-check run put the annual figure at 24.8% with the platform random source and 24.8% with the seeded generator - 0.00 points apart at the printed precision - so the number is the maths and not the dice.

Second, and more important for a decade chart: the expected hottest share falls as the sample grows (12.0% → 10.6% → 10.1%) while the expected spread in absolute counts grows (24 → 77 → 386 digits). Bigger samples look more dramatic in a bar chart and are simultaneously closer to flat. Ten years will always produce a taller bar than one year; that is not evidence of anything.

The Detection Limits

Flip the same arithmetic into the question an analyst actually asks - how large must a real shift be before a series of this length can see it? At two standard deviations, on a digit whose fair share is 10.00%:

A single market's year can only see a digit running 24% above fair. A single market's decade can only see 8%. To resolve a one-point change you need 3,600 digits - 5.8 market-years - and for half a point, 14,400 digits, or 23.0 market-years of one market that declares twice a day and takes one weekday off. This is why pooling matters so much and why it is so rarely disclosed: the same decade that is nearly blind per market is quite sharp across all 25 of them. Both statements are true, and a chart never tells you which one it is showing. The bet-sizing consequences of thin edges are worked through in the win-probability analysis; the equivalent per-window reasoning on the tooling side is in the chart-software audit.

Ten Bars on a Chart: Why a "Hot Year" Almost Always Exists

A decade trend chart is usually ten bars, one per year, for one market or one digit. That is exactly the structure that manufactures a discovery out of nothing, and you can measure the manufacturing rate. Simulating ten independent annual slices of 626 fair digits each, 40,000 times over:

Read those as a forecast of what any decade chart will contain. Draw ten bars for one market and, with no trend anywhere in the data, there is a 94% chance at least one year will look like an outlier to the eye, and about two and a half years on average will cross the two-sigma line a careful analyst might flag. Fit a straight line to the ten yearly shares and roughly one in twelve will pass the conventional two-sigma test on a generator that has no direction at all. Do that twenty-five times across a catalogue and about twenty "trends" appear per decade as pure noise; five markets - fifty independent market-digit series - are already enough to make at least one of them a near-certainty, at 98.6% - which is why the honest companion number to every trend claim is not its p-value but its multiple-comparison count: how many series were drawn before this one was pointed at.

There is one more trap in the best-and-worst-year figure. The expected spread of 3.68 points is not a bias; it is the sum of two maxima drawn from the same flat distribution, and it shrinks towards zero as you add years only if you also add data per year. A decade of one market adds years but not enough per-year observations to make the bars individually trustworthy, which is the worst available trade: ten noisy points that invite a line through them. The same construction, examined as a ranking over shorter windows, is dissected in when a number is called due.

"It's Due": Recurrence at Annual and Decadal Scale

Long series get used for gap arguments - this patti has not appeared in three years, it is due. Recurrence is where a decade genuinely helps, and the numbers are worth having precisely, because they show how fast the useful part saturates.

The 220 is arithmetic, not a survey figure - it is the count of non-decreasing triples over the digits 0-9, derived in the page that works it out - and here it is recomputed by enumeration in the same script as everything else. The consequence for a decade: the jodi and patti spaces close inside the first year. A specific jodi fails to appear at all across a full market-year 0.19% of the time, and about 0.2 of the 100 jodis are missing from an average year; across a decade, the probability that a given jodi never appears is 4.65 × 10^-28 - a one in 2×10²⁷ event, indistinguishable from impossible.

So the ten-year series cannot support "it is due" in any of the three spaces a Matka player names. It can only support the honest version, which is that gap lengths are exponentially distributed and a long gap is a fact about the tail, not a debt. Where the decade genuinely adds reach is the ordered panna: 465 of 1,000 in one year against 998 of 1,000 across ten. That is a real, monotone gain from more history - and notice what it buys: coverage of the outcome space, not information about the next draw. Which is the same distinction the tooling audit reached from the other direction.

Change Points: Where a Decade Is Blind by Construction

The most valuable thing a long series could tell you is the thing it is worst at detecting: the moment the rules changed. A step halfway through the decade is strictly harder to see than a level shift across the whole decade, because the test has to compare two halves rather than one sample against a constant.

A decade can only see a regime change that moves a digit's share by more than 1.5 points - a change of more than 15% in relative terms - at two sigma, and only if the analyst has already suspected the boundary and placed it. If the change is gradual, or confined to a third of the span, or affects two digits in opposite directions, the effective sample shrinks further and the limit worsens. That is the cruel symmetry of this page: the section that makes a decade valuable - crossing many regime changes - is the section that makes it statistically blind. The decade is the instrument you would reach for exactly when the rules moved, and it is the instrument least able to notice.

What Actually Survives: Money, Charts, and the Paper Trail

Retention is not the only deletion path, and the differences between them reveal the product's real priorities more clearly than any policy document.

Three things fall out of that ledger that no marketing page about historical data would volunteer.

One: the audit trail is on a shorter leash than the data it audits. V49__result_deletion_audit_logs.sql opens with an instruction, verbatim: these tables "must NEVER be truncated or cleaned aggressively - they are permanent audit records". V48, which is the file that actually configures deletion, gives result_deletion_logs a 15-day lifetime - 8.3% of the 180-day data lifetime it documents. Two migrations, both applied, one contradicted by the other, and the contradicted one wins because it is the one wired to the scheduler.

Two: the evidence is joined to the thing it evidences. V70__cascade_delete_result_deletion_logs.sql adds FOREIGN KEY (market_day_id) REFERENCES market_days(id) ON DELETE CASCADE to the deletion log. Its stated motive, in its own comment, is to "Fix 409 Conflict constraint violations when deleting a Market" - which it does, by making the record of a deletion leave when the deleted row leaves. So the daily cleanup purge takes the day and its paper trail in the same statement, and a deletion-log row cannot outlive the market_day it describes. For a decade-long forensic question - was this result ever changed? - the answer is that the system is designed to be unable to say.

Three: two services do the same job. ResultDeletionService and MainMarketResultDeletionService both capture a snapshot and write a deletion log. Duplication of this kind is benign in the short term and expensive in the long one, because the two drift, and the archive that a decade depends on is exactly the kind of thing one of them starts writing and the other does not.

Meanwhile the archive asymmetry from the previous section stands: the product will keep every rupee you ever staked, forever, and cannot keep the number it was staked on for six months. That is a defensible engineering choice - money has a legal life, charts do not - but it is flatly incompatible with marketing a decade of trends.

What an Honest Ten-Year Archive Would Require

Everything above is a critique, so here is the constructive half: the specification a Matka product would have to meet before "10 years of trends" is a statement you could check rather than a promise you would have to trust. Each item is stated as something a reader or an operator could verify from outside, because that is the only kind of requirement that has ever improved anything.

Six of those eight are bookkeeping, not statistics, and none of them are expensive. That ordering is the real finding of this audit: the obstacle between a Matka product and a decade of usable history is not modelling talent. It is a defaults review nobody scheduled.

Frequently Asked Questions

Does any Matka website really have ten years of data?

Some archives genuinely reach back years, particularly community and print-derived collections that were never tied to a betting product's database. What this audit shows is what to look for when a product claims it: the retention configuration behind the chart table. In the system examined here, the answer is 180 days - 181 dates counted inclusively - against a deepest page window of 1,097 dates and a JSON feed of 731. A decade needs 3,652. The claim and the storage differ by 20.18 times, and asking one question ("what was the result on this date five years ago?") settles it in either direction.

Why does a 180-day retention delete only complete days?

Because the cleanup predicate is result_status = 'FULL_DECLARED' and result_status has seven states. It is a sensible safety rule - do not delete a day that might still be settled or disputed - and an unfortunate archival consequence: six of seven statuses are immortal. Half-declared and pending days accumulate forever while finished days expire at six months, so the long-run residue of the table is biased towards the days that did not complete. That is why "the purge keeps the safe rows" and "the purge keeps the useful rows" are different sentences.

Can a ten-year chart show a yearly pattern?

It can show ten bars, which is not the same claim. For one market declaring twice a day with one weekday off, a year contributes about 626 ank digits, and the noise floor at that sample is 2.40 points of share on a digit whose fair rate is 10% - so a year-to-year difference has to exceed roughly a 24% relative gap before a single market's data can distinguish it from chance. Even a full decade of one market only reaches 0.76 points. And because a ten-way digit crosses its own two-sigma mark about once in four years, a decade of one market contains on average 2.47 years that will look anomalous and will not be; across a 25-market catalogue, about 62 such year-cells per decade.

Why do two "last 10 years" analyses disagree?

Usually the anchor, and the disagreement is measurable before any statistics are involved. A trailing decade ending at the date this audit was run starts 2016-10-28; the calendar decade 2016-2025 starts 301 dates earlier, so the two windows share 3,352 of 3,653 dates and differ on 301. One year is far worse: a trailing 366-date window and calendar-2025 share just 65 dates - 17.8% overlap. Add the schema's three different definitions of a recorded day and the fact that no query in 306 source files asks for more than 1,097 dates, and honest disagreement is the expected outcome rather than an anomaly.

Does more history help at all?

Yes, in two specific ways that are easy to miss because they are not the way the marketing uses "history". Pooling across markets sharpens the same decade enormously: 0.76 points of detection per market against 0.15 points across all 25 in the same period - a real bias becomes visible when you stop pretending one market's year is a sample. And coverage improves monotonically: a market-year sees 465 of the 1,000 ordered pannas, a market-decade sees 998. What more history does not do is make a gap argument work, or make a mid-series regime change visible: a step needs 1.52 points to show at a decade's midpoint against 0.76 for a level shift across the whole thing.

What should I check before trusting any historical Matka dataset?

Four questions, in order, all answerable from outside. What is the retention window behind the numbers you are being shown? What counts as a recorded day - both sessions, either session, or a row that exists? What was the calendar in the historical year you are analysing, and how is that known rather than inferred? And what is the fairness baseline for the exact n you are looking at - because without it, "hottest digit this year" is a description of the sample rather than a finding about the draw. Anything that cannot answer the first question has no decade to discuss; the other three determine whether the decade it does have means anything. The reader-side skills for verifying all four start with reading a result line properly and pulling an older result by date.

Is this the same as the history of the game?

No, and the conflation is worth resisting. The evolution of Matka - the paper slips, the bazaar era, the digit formats, the legal changes - is treated as history in the origins-to-digital-age piece, and it is a genuine and much longer record than any database here. A "historical data" page is about rows. Rows have retention policies. That difference is the whole subject of this one.