Wie viel Speicher Versionen in SharePoint wirklich belegen

Es gibt eine Annahme, die ich seit Jahren in verschiedenen Varianten höre: SharePoint nutzt doch Shredded Storage, also speichert es bei Versionen nur die Unterschiede. Das klingt vernünftig, stützt sich auf eine echte Technologie und führt am Ende zu dem Schluss, dass die Versionierung in Sachen Speicherplatz fast gratis ist.

Ist sie nicht. Und weil sich diese Behauptung messen lässt, haben wir sie gemessen.

Dieser Artikel ist keine Meinung. Er ist ein Messprotokoll aus einem Live-Mandanten von Microsoft 365, ergänzt um Zitate aus der Dokumentation von Microsoft. Alle Zahlen unten können Sie in Ihrer eigenen Umgebung nachvollziehen – das Vorgehen beschreibe ich einschließlich der konkreten Abfragen.

Was genau behauptet wird

Der Mythos hat zwei Teile, und es lohnt sich, sie zu trennen, denn einer davon ist wahr:

1. „SharePoint nutzt Shredded Storage.“ Wahr – es ist ein realer Mechanismus, den Microsoft in SharePoint Server 2013 eingeführt hat.
2. „Also belegen Versionen nur den Unterschied zur vorherigen Version.“ Falsch, zumindest in dem einzigen Sinn, den ein Kunde beobachten und bezahlen kann: bei der Anrechnung auf das Kontingent.

Der Unterschied zwischen diesen beiden Sätzen ist der Kern des ganzen Missverständnisses, und wir kommen in einem eigenen Abschnitt darauf zurück.

Methode

Gemessen am 2. September 2026 in einem produktiven Mandanten von Microsoft 365 (SharePoint Online), auf einer Demo-Website mit einer Dokumentbibliothek in der Standardkonfiguration: Versionierung aktiviert, Nebenversionen deaktiviert, Limit von 500 Hauptversionen.

EnableVersioning: true
EnableMinorVersions: false
MajorVersionLimit: 500

Die Daten werden über die SharePoint-REST-API gelesen, die die Größe jeder Version einzeln zurückgibt:

/_api/web/GetFileByServerRelativeUrl('<pfad>')/Versions?$select=VersionLabel,Size

Die Spalte Size ist in der Dokumentation von Microsoft zum Bericht über die Speichernutzung durch Versionen eindeutig als „The size of the version in bytes“ beschrieben. Es ist also weder eine Schätzung noch ein umgerechneter Wert – es ist die Größe, die der Dienst für die jeweilige Version erfasst.

Wir haben drei unabhängige Messungen durchgeführt: eine Beobachtung an einem realen Dokument, einen kontrollierten Versuch und eine Prüfung der Vollständigkeit einer Version.

Messung 1: ein reales Dokument mit drei Versionen

Ein methodisches Dokument im Word-Format, das auf dem üblichen Weg im Laufe mehrerer Monate entstanden ist und bearbeitet wurde.

Version	Erstellt	Größe
1.0	18.04.2026	33.485 B
2.0	28.08.2026	40.606 B
3.0 (aktuell)	02.09.2026	40.728 B
Gesamt		114.819 B

Die aktuelle Datei hat 40.728 Byte. Die Historie fügt weitere 74.091 Byte hinzu. Zusammen sind das also das 2,82-Fache der Dateigröße, die Sie in der Bibliothek sehen.

Sehen Sie sich die zweite Zeile genauer an, denn sie ist die aufschlussreichste. Zwischen Version 2.0 und Version 3.0 liegt ein Unterschied von 122 Byte. Würden Deltas gespeichert, würde Version 2.0 größenordnungsmäßig einige hundert Byte kosten. Erfasst werden für sie 40.606 Byte, also praktisch die volle Größe des Dokuments.

Messung 2: ein kontrollierter Versuch, bei dem sich kein einziges Byte des Inhalts änderte

Die Beobachtung an einem realen Dokument hat eine Schwäche: Der Inhalt hat sich zwischen den Versionen geändert, also könnte jemand einwenden, dass ein wesentlicher Teil der Datei neu geschrieben wurde. Deshalb ein zweiter Versuch, der so angelegt ist, dass er diesen Einwand vollständig ausschließt.

Vorgehen:

1. Wir haben eine Textdatei mit einer Größe von genau 1.048.576 B (1 MiB) in die Bibliothek hochgeladen.
2. Dreimal hintereinander haben wir ausschließlich Metadaten geändert – den Wert der Spalte Titel über REST. Der binäre Inhalt der Datei blieb unberührt.
3. Nach jedem Schritt haben wir die Größen aller Versionen ausgelesen.

Ergebnis:

Schritt	Aktuelle Version	Historische Versionen	Gesamt
Nach dem Hochladen	1.0 (1.048.576 B)	–	1,00 MB
Nach Metadatenänderung 1	2.0 (1.048.576 B)	1.0 = 1.048.576 B	2,00 MB
Nach Metadatenänderung 2	3.0 (1.048.576 B)	1.0, 2.0	3,00 MB
Nach Metadatenänderung 3	4.0 (1.048.576 B)	1.0, 2.0, 3.0	4,00 MB

Drei Änderungen, bei denen sich kein einziges Byte des Inhalts geändert hat, haben den Speicherplatz des Dokuments vervierfacht. Der Zuwachs pro Änderung betrug jedes Mal genau 1.048.576 Byte, also die volle Größe der Datei.

Das ist zugleich die Antwort auf die Frage, die mir von allen am häufigsten gestellt wird: Ja, auch eine Massenänderung von Metadaten – das Befüllen einer Spalte über Excel, die Neuklassifizierung einer Bibliothek, ein Skript über Tausende von Dateien – erzeugt bei jedem betroffenen Dokument eine neue Version, und jede davon zählt in voller Größe.

Messung 3: Ist eine historische Version eine vollständige Datei?

Ein letzter möglicher Einwand: Was, wenn die gemeldete Größe nur eine buchhalterische Fiktion ist und physisch gar keine vollständige Kopie existiert?

Wir haben den Inhalt der historischen Version 1.0 direkt heruntergeladen:

/_api/web/GetFileByServerRelativeUrl('<pfad>')/Versions(<id>)/$value

Übertragen wurden 1.048.576 Byte. Exakte Übereinstimmung mit der gemeldeten Größe. Eine historische Version verhält sich also wie eine vollständige, eigenständig herunterladbare Datei, nicht wie ein Inkrement, das aus etwas anderem zusammengesetzt werden müsste.

Die Testdatei wurde nach der Messung einschließlich Papierkorb entfernt.

Woher der Mythos stammt und warum er halb wahr ist

Shredded Storage gibt es tatsächlich. Und es gibt auch ein Dokument von Microsoft, das ihn genau im Zusammenhang mit der Größe von Versionen erwähnt – den Knowledge-Base-Artikel KB 3038333. Er beschreibt ein Szenario, das unserer zweiten Messung auffallend ähnelt: eine Datei mit 100 Megabyte, eine Änderung nur an den Metadaten und eine daraus resultierende gemeldete Größe von 200 MB.

Microsoft kommentiert das so:

„This behavior is by design. SharePoint Server 2013 uses SQL Server Shredded Storage to improve data transfer performance and reduce storage utilization. But the SharePoint quota component has no direct relationship to how SQL Server stores it physical data. Therefore, the quota component can’t report on the space that’s used on SQL Server physical storage.“

Hier steckt der ganze Widerspruch in einem einzigen Zitat. Shredded Storage ist ein Mechanismus innerhalb von SQL Server. Die Kontingentkomponente steht in keiner direkten Beziehung zu ihm und kann den physischen Speicherplatz in SQL nicht ausweisen. Dieser Satz wird oft als Beweis zitiert, dass „es real weniger belegt“ – er sagt aber etwas anderes und deutlich weniger Angenehmes: Das Kontingent weiß nichts über die physische Speicherung und rechnet mit vollen Größen.

Bei zwei Dingen muss man dabei ehrlich sein:

• Der zitierte Artikel betrifft SharePoint Server 2013, also ein lokales Produkt mit SQL Server. Er lässt sich nicht mechanisch auf SharePoint Online übertragen – SPO speichert Inhalte anders, und Microsoft veröffentlicht keine Details zu seiner internen Organisation.
• Die physische Speicherung ist eine andere Frage als das Kontingent, und in SharePoint Online lässt sie sich nicht beantworten. Wir behandeln sie im folgenden Abschnitt.

Bedeutung hat nur eine einzige Zahl: die, die auf Ihr Kontingent angerechnet wird. Und das ist nach unserer Messung wie nach der Dokumentation die volle Größe jeder Version.

Physisch muss es nicht das Vierfache sein – nur lässt sich das nicht feststellen

Fast jeder, der bis hierher liest, fragt dasselbe: Liegt dieses Dokument mit drei Versionen wirklich viermal in der Datenbank? Die Antwort hängt von der Plattform ab, und bei einer davon lautet sie „Wir wissen es nicht“.

Lokales SharePoint Server 2013 und neuer. Ein Dokument wird in „Shreds“ aufgeteilt, die zeilenweise in der Tabelle DocStreams in der Inhaltsdatenbank gespeichert werden. Entsteht eine neue Version, werden nur die geänderten Shreds geschrieben; die unveränderten werden der neuen Version zugeordnet und zwischen den Versionen geteilt. Physisch ist das also ungefähr eine Kopie plus Änderungen, nicht vier.

Zwei Dinge schmälern diese Einsparung jedoch, und in den damaligen Materialien wurden sie nicht erwähnt. Office-Dateien sind ZIP-Container, sodass eine kleine logische Änderung die Komprimierung über einen großen Teil des Archivs neu schreiben kann – es ändern sich dann deutlich mehr Shreds, als dem Umfang der Bearbeitung entspräche. Und bei einer reinen Metadatenänderung wird vom Inhalt überhaupt nichts geschrieben, trotzdem steigt das Kontingent um die volle Dateigröße. Das ist genau das Szenario aus dem zitierten KB-Artikel.

SharePoint Online. Hier gibt es keine Antwort. Microsoft dokumentiert die interne Organisation des SPO-Speichers nicht, an seine Datenbanken kommen Sie nicht heran, und keine Schnittstelle gibt die physische Belegung zurück. Alles, was Sie zu diesem Thema finden, ist eine Ableitung aus dem lokalen Produkt, keine Messung – und das gilt auch für diesen Artikel.

Für Entscheidungen zum Speicher ist das zum Glück unerheblich, denn es gilt eine einfache Regel: Auf das Kontingent werden Versionen so angerechnet, als wäre jede einzeln als vollständige Datei gespeichert. Und das Kontingent ist das Einzige, was Sie sehen, woran Sie stoßen und was Sie bezahlen. Eine etwaige physische Einsparung ist die Einsparung des Speicherbetreibers, nicht Ihre.

Ein indirekter Beweis aus der Dokumentation

Es gibt noch ein Argument, das beim Lesen der Dokumentation auffällt und die ganze Sache von der anderen Seite bestätigt.

Microsoft hat 2024 automatische Limits für den Versionsverlauf eingeführt und beschreibt sie im Leitfaden zur Speicherplanung so:

„Under automatic settings intermittent older versions are trimmed over time, resulting in 96% version storage reduction in six months period compared to count limits.“

Und etwas weiter, an einem anderen Beispiel, „~94% reduction in version storage used compared to applying count limits only“.

Diese Zahlen ergeben nur dann einen Sinn, wenn jede Version Speicherplatz proportional zur Dateigröße belegt. Würden Deltas gespeichert, könnte das Bereinigen eines Teils der Zwischenversionen keine so dramatische Einsparung bringen – man kann nichts einsparen, wo fast nichts ist. Microsoft hat die automatischen Limits nicht eingeführt, weil Versionen billig wären.

Was das praktisch bedeutet

Die Versionierung ist eine der nützlichsten Eigenschaften von SharePoint, und der Rat „Schalten Sie sie ab“ wäre falsch. Ziel ist, bewusst für sie zu bezahlen.

Aktivieren Sie automatische Limits für den Versionsverlauf. Microsoft empfiehlt sie selbst als Standardwahl, und das Prinzip ist vernünftig: Der Wert einer alten Version für eine Wiederherstellung sinkt mit der Zeit. Der Algorithmus ist dokumentiert, und es lohnt sich, ihn zu kennen, denn daran erkennen Sie, was sich noch wiederherstellen lässt:

• alle Versionen innerhalb des Limits von 500 in den ersten 30 Tagen,
• stündliche Versionen zwischen dem 30. und dem 60. Tag,
• tägliche Versionen zwischen dem 60. und dem 180. Tag,
• wöchentliche Versionen nach 180 Tagen, bis die Obergrenze von 500 Versionen erreicht ist.

Führen Sie vor jeder Änderung eine „Was wäre, wenn“-Analyse durch. SharePoint kann einen Bericht über die Speichernutzung durch Versionen für eine Website oder Bibliothek erstellen und die Auswirkung eines Limits modellieren, bevor Sie es festlegen. Das lohnt sich – bei großen Websites läuft der Bericht mehrere Tage, aber Sie erhalten echte Zahlen statt einer Schätzung.

Das Bereinigen vorhandener Versionen ist unumkehrbar. Versionen, die durch ein Limit oder einen geplanten Auftrag gelöscht werden, umgehen den Papierkorb und lassen sich daraus nicht wiederherstellen. Eine Version, die ein Benutzer manuell löscht, landet dagegen im Papierkorb – und belegt den Platz weiter, bis der Papierkorb geleert wird.

Rechnen Sie mit Ausnahmen. Bei Inhalten unter einer Aufbewahrungsrichtlinie oder in einem eDiscovery-Hold werden Versionslimits ignoriert, solange die Ausnahme besteht. Bei Dokumenten, die als Datensatz gekennzeichnet sind, ist das Löschen von Versionen vollständig gesperrt. Wer sich darauf verlässt, dass ein Limit alles löst, kann überrascht werden.

Achten Sie auf Massenänderungen von Metadaten. Wie die zweite Messung gezeigt hat, sind sie der billigste Weg, Ihren Speicher aufzublähen, ohne ein einziges nützliches Wort hinzuzufügen. Vor einem Migrationsskript oder einer massenhaften Neuklassifizierung sollten Sie abwägen, ob die Versionierung die ganze Zeit aktiviert bleiben muss.

Zur Veranschaulichung, was das im normalen Betrieb bedeutet: Eine Präsentation mit 5 MB, die ein Team im Laufe eines Jahres zweihundertmal bearbeitet, belegt bei einem Limit von 500 Versionen rund ein Gigabyte. Eine einzige Datei.

Grenzen dieser Messung

Damit das Fazit ehrlich ist, gehört auch dazu, was wir nicht nachgewiesen haben:

• Gemessen haben wir die vom Dienst gemeldeten Größen, nicht die physisch belegten Blöcke im Speicher von Microsoft. Diese lassen sich von außen nicht messen, und Microsoft veröffentlicht sie nicht.
• Die Schnittstelle StorageMetrics, mit der wir die Angaben zusätzlich auf Ebene der Bibliothek prüfen wollten, lieferte im getesteten Mandanten Nullen – eine Kontrolle aus dieser Richtung war uns also nicht möglich.
• Die aggregierte Speichernutzung einer Website wird laut Dokumentation verzögert aktualisiert, in der Größenordnung von bis zu 48 Stunden. Eine sofortige Messung der Differenz am Kontingent ist daher keine zuverlässige Methode, und wir haben uns bewusst nicht darauf gestützt.
• Gemessen in einem Mandanten, in einer Bibliothek, in der Standardkonfiguration (500 Hauptversionen, Nebenversionen deaktiviert).

Nachgewiesen ist dagegen: Die Zahl, die SharePoint für jede Version erfasst – und auf der das Kontingent beruht –, entspricht der vollen Dateigröße, und eine historische Version ist ein eigenständig herunterladbares Ganzes. Für Entscheidungen zum Speicher ist das die relevante Größe.

Was Sie mitnehmen sollten

1. Nein, Versionen sind keine Deltas. Für das Kontingent zählt jede Version in voller Dateigröße. Ein Dokument mit drei Versionen belegt etwa das Dreifache dessen, was die Spalte Größe anzeigt.
2. Auch eine reine Metadatenänderung ist nicht gratis. Wir haben bei jeder solchen Änderung einen Zuwachs von genau der vollen Dateigröße gemessen. Massenänderungen an Spalten sind aus Sicht des Speichers eine teure Operation.
3. Shredded Storage betrifft etwas anderes. Es ist ein Mechanismus innerhalb von SQL Server beim lokalen SharePoint, und Microsoft schreibt selbst, dass die Kontingentkomponente in keiner direkten Beziehung zu ihm steht. Als Argument „Versionen sind billig“ hält es nicht.
4. Eine Lösung existiert und ist dokumentiert. Automatische Limits für den Versionsverlauf, der Nutzungsbericht, die „Was wäre, wenn“-Analyse und das Bereinigen. Microsoft selbst nennt eine Einsparung von 94 bis 96 Prozent gegenüber reinen Versionsanzahl-Limits.

---

Bei EP365 behandeln wir Speicher und Governance von SharePoint im Rahmen einer Prüfung der Umgebung und eines Governance-Konzepts – einschließlich der Frage, was Sie die Historie kostet, von der Sie nichts wissen. Wenn Ihr Kontingent schneller wächst, als es sinnvoll ist, melden Sie sich bei uns, und wir gehen es anhand Ihres konkreten Mandanten durch.

Im nächsten Teil sehen wir uns an, was mit Inhalten am Ende ihres Lebenszyklus geschieht – Aufbewahrung, Archivierung und warum gerade der Lebenszyklus darüber entscheidet, ob Ihre KI aus gültigen Dokumenten antwortet.