WeatherNext 3 Makes Weather a Bigger Data Contract • The Weighted Average

Google launched WeatherNext 3 on September 3 with hourly forecast refreshes and key surface variables at roughly 5 km resolution. Its 0.05-degree temperature grid, compared with the 0.25-degree grid in the WeatherNext 2 data catalog, implies approximately 25x as many cells over the same geographic area—not a free, drop-in upgrade to an existing data pipeline.

Reconstructed on September 7, 2026, from records available by September 3, 2026.

Sharper weather changes the ingestion plan

The calculation is spatial, not financial: 0.25 divided by 0.05 equals five cells along each axis, and five squared equals 25. It compares nominal temperature-grid density at matched geographic coverage. It does not mean forecasts are 25 times more accurate, cloud bills are 25 times larger, or every field in the new product has the same resolution. Those distinctions matter before an operator starts multiplying storage estimates.

Google describes several resolutions rather than a uniform grid. Key surface variables, including temperature and moisture, reach 5 km; other surface variables are at 10 km; atmospheric variables remain at 25 km. The right integration unit is therefore a variable, geographic extent, forecast horizon, and refresh schedule. Downloading everything because the old pipeline did so may be the wrong default when only local temperature is needed.

The new model also changes the input clock. In the WeatherNext 3 paper, submitted September 3, researchers describe generating new forecasts every hour from low-latency geostationary satellite data. They contrast this with the six-hour initialization cycle of traditional global models. Google’s older Earth Engine catalog likewise lists WeatherNext 2 initialization at 00z, 06z, 12z, and 18z. An application that treats the old cycle as an implicit scheduling contract should revisit it.

Do not confuse that refresh interval with a forecast’s output time step. Google’s November 2025 WeatherNext 2 announcement already advertised predictions with resolution down to an hour. WeatherNext 3’s important addition is a newly initialized forecast grounded in more recent observations, not simply another timestamp inside an older run. Without that distinction, a product team could label stale data as fresh because its valid times look sufficiently granular.

The technical paper also describes learning from sparse station observations to predict temperature and dewpoint conditioned on local geography. That offers a plausible route to better handling coastlines, valleys, and other places where coarse grids smooth away relevant variation. It is a methodological improvement worth testing, not evidence that every particular site now has a dependable local forecast.

Google says the forecast data can be queried through BigQuery and Earth Engine or downloaded from Cloud Storage. That makes this an integration decision rather than a requirement to train and operate a weather model. Buyers still need to choose their permitted access route, verify the fields actually delivered through it, and measure the cost of moving and retaining the data their application uses.

This is adjacent to the archive’s argument for rollback and provenance in Earth AI systems. A new model version should not silently overwrite the record of what an operator knew when a decision was made. It is also relevant to Broadcom’s capacity-driven AI expansion: better forecasts can inform energy planning, but the usefulness of an AI service depends on the surrounding operational contract, not just the model’s resolution.

Test the decision, not the prettier map

The strongest near-term candidates are teams whose decisions are sensitive to local temperature, wind, cloud cover, or precipitation and that can compare predictions with observed outcomes. Renewable-energy operators are an explicit audience. Google’s launch note highlights 100-meter wind forecasts, cloud cover, and solar-radiation variables for estimating wind and solar production. These are forecast inputs to an operating process, not guarantees of delivered electricity.

Start by preserving initialization time, valid time, model version, and the observation or forecast source with each result. A revised prediction may be better, but it should remain distinguishable from the forecast used when a schedule or commitment was made. Backtesting with a later forecast accidentally substituted for the original can make a decision system look more prescient than it was.

Then compare the new feed in parallel with the existing one. Score the local decision: was a weather-sensitive job scheduled more reliably, was an energy estimate better calibrated, or did an alert arrive with useful lead time? Include adverse cases as well as routine days. An aggregate improvement can coexist with unacceptable performance on the rare events for which an operator actually buys weather information.

Google’s precipitation claims require particular care. Its announcement reports different improvements against different evaluation references and separately advertises up to 50% more accurate precipitation forecasts for consumer planning a day or more ahead. Those are not interchangeable with the temperature-grid calculation. Neither the word “accuracy” nor an attractive map supplies a common denominator across precipitation probability, station temperature, and the economics of a specific energy asset.

There is also an explicit safety boundary. Google directs users to local meteorological agencies or national weather services for official forecasts, severe-weather warnings, and public-safety advisories. A business should not replace that authority with a consumer product integration. Keep official alerting and escalation paths intact while evaluating the new model as an additional operational input.

The migration cost is measurable but not supplied by the announcement. It includes data access, query and storage charges, changes to ingestion and versioning, and the work of validating local performance. The 25x density calculation is a reason to request a sample and inspect its size, not a substitute for a bill. Compression, geographic filtering, variables, and retained forecast horizons can all alter the actual workload.

Evidence that would change the verdict includes poor calibration at the relevant sites, inconsistent availability through the chosen data route, or ingestion costs that outweigh the decision improvement. Strong local backtests followed by a successful parallel run would justify switching selected variables first. WeatherNext 3 makes the weather feed richer and potentially more timely. The operator’s job is to make that richness useful without losing the audit trail.