<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn" -->

---
title: Index Rebuild Job, 1998 to 2026: An Obituary | daily.dev
description: Nightly index rebuild jobs made sense for spinning disks but may waste effort on SSDs, a SQL Server 2025 experiment suggests. On tables built to 99.3%...
canonical: https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Index Rebuild Job, 1998 to 2026: An Obituary | daily.dev
og:description: Nightly index rebuild jobs made sense for spinning disks but may waste effort on SSDs, a SQL Server 2025 experiment suggests. On tables built to 99.3%...
og:url: https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn
og:image: https://api.daily.dev/og/posts/WmlZXaBYn.png
og:image:alt: Index Rebuild Job, 1998 to 2026: An Obituary
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Index Rebuild Job, 1998 to 2026: An Obituary

**[SQL Authority](https://daily.dev/sources/sql-authority)** · 7 min read · 0 upvotes · 0 comments

## Summary

Nightly index rebuild jobs made sense for spinning disks but may waste effort on SSDs, a SQL Server 2025 experiment suggests. On tables built to 99.3% fragmentation and 68% page density, a scan's cold reads fell from 38,445 to 26,402 after REBUILD, because pages dropped from 38,000 to 26,000, not because reads got faster. For seeks, warm performance was nearly identical across left-alone, reorganized and rebuilt indexes. REORGANIZE took 16 seconds and logged 595 MB; REBUILD took 0.85 seconds and logged 1.1 MB. The author argues the real gains people credited to rebuilds mostly came from the statistics refresh that happens as a side effect.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://blog.sqlauthority.com/2026/10/27/obituary-nightly-index-rebuild>

## Questions this post answers

### Does rebuilding a SQL Server index actually make seeks faster once the data is cached in memory?

No, warm seek performance is nearly identical whether the index was left alone, reorganized, or rebuilt. In one test, 10,000 seeks across all three states landed within 40 logical reads and 3 milliseconds of each other. The only measured benefit of rebuilding appeared on cold reads, where maintained indexes needed about 30 percent fewer physical reads because they had fewer pages to fetch.

_Anyone tuning SQL Server maintenance jobs can pressure-test assumptions like this using benchmarks shared on daily.dev._

### How much transaction log does REORGANIZE write compared to REBUILD on a SQL Server index?

On a million-row table, REORGANIZE wrote 595 MB to the transaction log and took 16 seconds, while REBUILD wrote only 1.1 MB and took 0.85 seconds. The rebuild was minimally logged because the database was in simple recovery mode; in full recovery, a rebuild would log the entire index instead.

_Developers weighing index maintenance strategies can track real-world benchmarks like this through daily.dev._

### Why does rebuilding a fragmented SQL Server index improve scan performance?

Scan reads drop because rebuilding fills pages more densely, not because individual page reads become faster. In one test, a table at 99.3 percent fragmentation and 68 percent page density needed 38,445 reads; after rebuild, page density rose to 98 percent and reads fell to 26,402, matching the drop in page count.

_Engineers debugging slow scans can dig into page density versus fragmentation details surfaced on daily.dev._

## Similar posts on daily.dev

- [Your Index Rebuild Maintenance Plan Is Rebuilding Indexes Nobody Uses](https://daily.dev/posts/your-index-rebuild-maintenance-plan-is-rebuilding-indexes-nobody-uses-jkk3542hy) · SQL Authority · 0 upvotes · 0 comments
- [Rebuild large indexes on Aurora PostgreSQL with Blue/Green Deployments](https://daily.dev/posts/rebuild-large-indexes-on-aurora-postgresql-with-blue-green-deployments-ahloqjc3j) · AWS Database Blog · 0 upvotes · 0 comments
- [Processing 11 million rows in minutes instead of hours](https://daily.dev/posts/processing-11-million-rows-in-minutes-instead-of-hours-jgagdggzi) · stitcher.io · 277 upvotes · 5 comments
- [The unbearable lightness of one more index](https://daily.dev/posts/the-unbearable-lightness-of-one-more-index-kpu7ly7ec) · Planet PostgreSQL · 4 upvotes · 0 comments

---

Tags: [#microsoft-sql-server](https://daily.dev/tags/microsoft-sql-server)

[View this post on daily.dev](https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Index Rebuild Job, 1998 to 2026: An Obituary","url":"https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn"},"datePublished":"2026-10-27T01:44:20.951Z","dateModified":"2026-10-27T01:44:56.462Z","description":"Nightly index rebuild jobs made sense for spinning disks but may waste effort on SSDs, a SQL Server 2025 experiment suggests. On tables built to 99.3%...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/ce19563c0fca03a65a7db28b8aded91f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/ce19563c0fca03a65a7db28b8aded91f?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"SQL Authority","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"SQL Authority","logo":"https://media.daily.dev/image/upload/s--reCGnvgi--/f_auto,q_auto/v1780213436/logos/sql-authority?_a=BAMAMiWQ0","url":"https://daily.dev/sources/sql-authority"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"microsoft-sql-server","timeRequired":"PT7M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"SQL Authority","item":"https://daily.dev/sources/sql-authority"},{"@type":"ListItem","position":3,"name":"Index Rebuild Job, 1998 to 2026: An Obituary"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/index-rebuild-job-1998-to-2026-an-obituary-wmlzxabyn#faq","mainEntity":[{"@type":"Question","name":"Does rebuilding a SQL Server index actually make seeks faster once the data is cached in memory?","acceptedAnswer":{"@type":"Answer","text":"No, warm seek performance is nearly identical whether the index was left alone, reorganized, or rebuilt. In one test, 10,000 seeks across all three states landed within 40 logical reads and 3 milliseconds of each other. The only measured benefit of rebuilding appeared on cold reads, where maintained indexes needed about 30 percent fewer physical reads because they had fewer pages to fetch. Anyone tuning SQL Server maintenance jobs can pressure-test assumptions like this using benchmarks shared on daily.dev."}},{"@type":"Question","name":"How much transaction log does REORGANIZE write compared to REBUILD on a SQL Server index?","acceptedAnswer":{"@type":"Answer","text":"On a million-row table, REORGANIZE wrote 595 MB to the transaction log and took 16 seconds, while REBUILD wrote only 1.1 MB and took 0.85 seconds. The rebuild was minimally logged because the database was in simple recovery mode; in full recovery, a rebuild would log the entire index instead. Developers weighing index maintenance strategies can track real-world benchmarks like this through daily.dev."}},{"@type":"Question","name":"Why does rebuilding a fragmented SQL Server index improve scan performance?","acceptedAnswer":{"@type":"Answer","text":"Scan reads drop because rebuilding fills pages more densely, not because individual page reads become faster. In one test, a table at 99.3 percent fragmentation and 68 percent page density needed 38,445 reads; after rebuild, page density rose to 98 percent and reads fell to 26,402, matching the drop in page count. Engineers debugging slow scans can dig into page density versus fragmentation details surfaced on daily.dev."}}]}
```

