data-system-timeline/index.html at main · Data-System-School/data-system-timeline · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="description" content="A visual chronology of 83 major data-system breakthroughs from the 1960s through 2026, covering databases, distributed systems, cloud warehouses, streaming, and AI-native data infrastructure." />
<meta property="og:title" content="Data Systems Development Timeline, 1960s–2026" />
<meta property="og:description" content="83 major data-system breakthroughs from the 1960s through 2026." />
<meta property="og:type" content="website" />
<meta name="twitter:card" content="summary" />
<meta name="twitter:title" content="Data Systems Development Timeline, 1960s–2026" />
<meta name="twitter:description" content="83 major data-system breakthroughs from the 1960s through 2026." />
<link rel="icon" type="image/svg+xml" href="favicon.svg" />
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;700&family=Space+Grotesk:wght@400;500;700&display=swap" />
<title>Data Systems Development Timeline, 1960s–2026</title>
<link rel="canonical" href="https://datasystem.school/data-system-timeline/" />
<link rel="alternate" hreflang="en" href="https://datasystem.school/data-system-timeline/" />
<link rel="alternate" hreflang="zh-Hant" href="https://datasystem.school/data-system-timeline/zh/index.html" />
<link rel="alternate" hreflang="x-default" href="https://datasystem.school/data-system-timeline/" />
<style>
/* ============================================================
   Data System Timeline — Neo-Brutalist Blueprint
   Matches the Data System School landing page: paper + hard black
   borders + offset shadows + flat clashing blocks + grotesk type,
   kept on a disciplined grid so it stays usable.
   ============================================================ */
:root {
    --bg: #fdfcf8;
    --bg-warm: #f4f1e7;
    --paper: #ffffff;
    /* Warm charcoal, not pure black — same ink as the landing page. */
    --ink: #35312a;
    --blue: #4272d7;
    --yellow: #f7e39a;
    --red: #c2564a;
    --tint-blue: #eaf2fa;
    --tint-red: #f9ece8;
    --tint-yellow: #faf3da;
    --muted: #5d594f;
    --muted2: #8a8578;
    --grid-line: #f0eee5;
    --shadow: rgba(53, 49, 42, 0.18);
    /* legacy alias — inline refs (footer link) still use --accent */
    --accent: #4272d7;
    --line: #837d6f;
    --band: #4b463c;
    --mono: 'JetBrains Mono', ui-monospace, Menlo, monospace;
}
* { box-sizing: border-box; }
html { scroll-behavior: smooth; }
body {
    margin: 0;
    font-family: 'Space Grotesk', system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
    color: var(--ink);
    background: var(--bg);
    background-image:
        linear-gradient(var(--grid-line) 1px, transparent 1px),
        linear-gradient(90deg, var(--grid-line) 1px, transparent 1px);
    background-size: 34px 34px;
    line-height: 1.55;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}
a { color: var(--blue); text-decoration: none; }
a:hover { text-decoration: underline; }
.wrapper { width: min(1220px, calc(100vw - 32px)); margin: 0 auto; }
.hero { padding: 56px 0 44px; }
.kicker {
    display: inline-flex; align-items: center;
    font-family: var(--mono);
    font-size: 11px; font-weight: 700;
    letter-spacing: .14em; text-transform: uppercase;
    color: var(--muted2);
}
.kicker::before { content: "// "; color: var(--blue); white-space: pre; }
h1 {
    font-size: clamp(2.1rem, 5.6vw, 4.4rem);
    line-height: .98;
    letter-spacing: -0.02em;
    text-transform: uppercase;
    font-weight: 700;
    margin: 20px 0 18px;
    max-width: 1050px;
}
.subtitle { max-width: 760px; color: #504b42; font-size: clamp(1rem, 1.4vw, 1.08rem); font-weight: 500; }
.stats {
    display: grid; grid-template-columns: repeat(4, minmax(0,1fr)); gap: 16px;
    margin: 34px 0 6px;
}
.stat {
    background: var(--paper); border: 2px solid var(--line);
    box-shadow: 4px 4px 0 var(--shadow);
    padding: 16px 18px;
}
.stat strong { display: block; font-size: 2rem; line-height: 1.1; letter-spacing: -0.02em; }
.stat span {
    font-family: var(--mono); font-size: 11px; font-weight: 700;
    letter-spacing: .06em; text-transform: uppercase; color: var(--muted2);
}
.controls-wrap {
    position: sticky; top: 0; z-index: 20;
    background: var(--bg);
    border-top: 2px solid var(--line); border-bottom: 2px solid var(--line);
}
.controls {
    display: grid; grid-template-columns: 1.6fr .9fr auto; gap: 12px; align-items: center;
    padding: 14px 0;
}
input, select, button { font: inherit; }
.search, .select {
    width: 100%; border: 2px solid var(--line); border-radius: 0;
    background: var(--paper); color: var(--ink); padding: 11px 14px;
    font-weight: 500;
    outline: none;
}
.search::placeholder { color: var(--muted2); }
.search:focus, .select:focus { outline: 3px solid var(--blue); outline-offset: 2px; }
.select option { color: var(--ink); }
.btn {
    display: inline-flex; align-items: center; justify-content: center; gap: 8px;
    border: 2px solid var(--line); background: var(--paper); color: var(--ink);
    padding: 11px 16px; cursor: pointer; white-space: nowrap;
    font-size: 13px; font-weight: 700; letter-spacing: .02em; text-transform: uppercase;
    box-shadow: 4px 4px 0 var(--shadow);
    transition: transform .08s ease, box-shadow .08s ease;
}
.btn:hover { transform: translate(2px, 2px); box-shadow: 2px 2px 0 var(--shadow); }
.btn:active { transform: translate(4px, 4px); box-shadow: 0 0 0 var(--shadow); }
.chips { display: flex; flex-wrap: wrap; gap: 8px; padding: 0 0 14px; }
.chip {
    display: inline-flex; align-items: center; gap: 6px;
    border: 2px solid var(--line); background: var(--paper); color: var(--ink);
    padding: 6px 11px; cursor: pointer;
    font-family: var(--mono); font-size: 11px; font-weight: 700;
    letter-spacing: .04em; text-transform: uppercase;
}
.chip:hover { background: var(--tint-blue); }
.chip.active { background: var(--yellow); }
.layout { display: grid; grid-template-columns: 300px minmax(0,1fr); gap: 28px; padding: 36px 0 70px; }
aside { position: sticky; top: 140px; align-self: start; max-height: calc(100vh - 156px); overflow-y: auto; scrollbar-width: thin; scrollbar-color: var(--muted2) transparent; }
.side-panel {
    background: var(--paper); border: 2px solid var(--line);
    box-shadow: 4px 4px 0 var(--shadow);
    padding: 20px 18px;
}
.side-panel h2 {
    font-size: 12px; font-weight: 700; margin: 0 0 10px;
    font-family: var(--mono); letter-spacing: .1em; text-transform: uppercase;
}
.side-panel h2::before { content: "// "; color: var(--blue); }
.side-panel p { color: var(--muted); font-size: .92rem; margin: 0 0 16px; }
.phase-map { display: grid; gap: 10px; margin-top: 14px; }
.phase { border: 2px solid var(--line); border-left: 6px solid var(--blue); background: var(--bg); padding: 10px 12px; }
.phase b { display: block; font-size: .94rem; }
.phase span { color: var(--muted); font-size: .84rem; }
.cat-list { margin: 14px 0 0; padding: 0; list-style: none; display: grid; gap: 8px; }
.cat-list li { display: flex; justify-content: space-between; gap: 10px; color: var(--muted); font-size: .86rem; border-bottom: 2px solid var(--grid-line); padding-bottom: 7px; }
.cat-list strong { color: var(--ink); font-family: var(--mono); font-size: .8rem; }
.era-section { margin: 0 0 48px; }
.era-heading {
    display: flex; align-items: center; justify-content: space-between; gap: 16px; margin: 0 0 20px;
    padding: 12px 18px;
    background: var(--band); color: #f6f4ed;
    border: 2px solid var(--line);
    box-shadow: 4px 4px 0 var(--shadow);
}
.era-heading span { font-size: 1.3rem; font-weight: 700; letter-spacing: -.01em; text-transform: uppercase; }
.era-heading strong { font-family: var(--mono); color: var(--yellow); font-size: 11px; font-weight: 700; letter-spacing: .06em; text-transform: uppercase; }
.timeline { position: relative; padding-left: 30px; }
.timeline:before { content: ""; position: absolute; left: 7px; top: 0; bottom: 0; width: 2px; background: var(--line); }
.milestone {
    position: relative; margin: 0 0 22px; padding: 20px;
    background: var(--paper);
    border: 2px solid var(--line);
    box-shadow: 4px 4px 0 var(--shadow);
}
.pin { position: absolute; left: -30px; top: 24px; width: 12px; height: 12px; background: var(--blue); border: 2px solid var(--line); }
.card-head { display: flex; justify-content: space-between; gap: 14px; align-items: flex-start; }
.year { font-family: var(--mono); color: var(--blue); font-weight: 700; font-size: .85rem; letter-spacing: .04em; }
h3 { margin: 4px 0 0; font-size: clamp(1.1rem, 2vw, 1.45rem); line-height: 1.12; letter-spacing: -.01em; }
.badge {
    flex: 0 0 auto; padding: 3px 9px;
    font-family: var(--mono); font-size: 10.5px; font-weight: 700;
    letter-spacing: .04em; text-transform: uppercase;
    color: var(--ink); border: 2px solid var(--line); background: var(--yellow);
}
.meta { display: grid; gap: 4px; color: var(--muted); margin: 12px 0 14px; font-size: .92rem; }
.meta span:first-child {
    font-family: var(--mono); font-size: 11px; font-weight: 700;
    letter-spacing: .06em; text-transform: uppercase; color: var(--muted2);
}
.problem, .solution, .impact {
    padding: 12px 14px; margin: 10px 0;
    border: 2px solid var(--line);
    font-size: .95rem;
}
.problem { background: var(--tint-red); }
.solution { background: var(--tint-blue); }
.impact { background: var(--tint-yellow); }
.problem strong { color: var(--red); }
.solution strong { color: var(--blue); }
.impact strong { color: var(--ink); }
.refs { display: flex; flex-wrap: wrap; gap: 8px; align-items: center; color: var(--muted2); margin-top: 14px; font-size: .85rem; }
.refs strong { font-family: var(--mono); font-size: 11px; letter-spacing: .06em; text-transform: uppercase; }
.refs a { display: inline-flex; align-items: center; gap: 6px; border: 1px solid var(--line); padding: 3px 8px; background: var(--paper); font-weight: 500; }
.refs a:hover { background: var(--tint-blue); text-decoration: none; }
.ddia { display: flex; flex-wrap: wrap; gap: 8px; align-items: center; color: var(--muted2); margin-top: 10px; font-size: .85rem; }
.ddia strong { font-family: var(--mono); font-size: 11px; letter-spacing: .06em; text-transform: uppercase; }
.ddia-chip {
    display: inline-flex; align-items: center; gap: 6px;
    border: 2px solid var(--line); background: var(--paper); color: var(--ink);
    padding: 3px 9px; cursor: pointer; user-select: none;
    font-family: var(--mono); font-size: 10.5px; font-weight: 700;
    letter-spacing: .04em; text-transform: uppercase;
    transition: background .15s ease;
}
.ddia-chip:hover { background: var(--tint-blue); }
.ddia-chip.active { background: var(--yellow); }
.ddia-why {
    margin-top: 10px; padding: 12px 14px;
    background: var(--tint-blue); border: 2px solid var(--line);
    color: var(--ink); font-size: .9rem; line-height: 1.55;
    animation: ddiaFadeIn .18s ease;
}
@keyframes ddiaFadeIn { from { opacity: 0; transform: translateY(-4px); } to { opacity: 1; transform: translateY(0); } }
.no-results { display: none; padding: 30px; text-align: center; color: var(--muted); border: 2px dashed var(--line); background: var(--paper); }
.footer { padding: 36px 0 70px; color: var(--muted); border-top: 2px solid var(--line); background: var(--bg-warm); }
.footer strong { color: var(--ink); }
/* GitHub star ask. Borrows .btn's hard-edged press, tinted yellow so it reads as
   a request rather than one more filter control sitting in the chrome. */
.star-cta {
    display: inline-flex; align-items: center; gap: 10px;
    border: 2px solid var(--line); background: var(--tint-yellow); color: var(--ink);
    padding: 11px 16px; text-decoration: none;
    font-family: var(--mono); font-size: 12px; font-weight: 700;
    letter-spacing: .04em; text-transform: uppercase;
    box-shadow: 4px 4px 0 var(--shadow);
    transition: transform .08s ease, box-shadow .08s ease;
}
.star-cta:hover { transform: translate(2px, 2px); box-shadow: 2px 2px 0 var(--shadow); }
.star-cta:active { transform: translate(4px, 4px); box-shadow: 0 0 0 var(--shadow); }
.star-cta .star { color: var(--red); font-size: 15px; line-height: 1; }
.hero .star-cta { margin-top: 26px; }
.star-block {
    margin: 26px 0 0; padding: 20px 22px;
    border: 2px solid var(--line); background: var(--paper);
    box-shadow: 4px 4px 0 var(--shadow);
}
.star-block h2 {
    margin: 0 0 9px; font-family: var(--mono); font-size: 11px; font-weight: 700;
    letter-spacing: .08em; text-transform: uppercase; color: var(--muted2);
}
.star-block p { margin: 0 0 16px; max-width: 640px; }
mark { background: var(--yellow); color: var(--ink); padding: 0 .12em; }
.collapse-toggle {
    display: none; width: 100%; border: 2px solid var(--line); background: var(--paper);
    color: var(--ink); padding: 11px 14px; cursor: pointer;
    font: inherit; font-size: 13px; font-weight: 700; letter-spacing: .02em; text-transform: uppercase;
    align-items: center; justify-content: space-between;
    box-shadow: 4px 4px 0 var(--shadow);
}
.collapse-toggle .toggle-icon {
    transition: transform .25s ease; display: inline-block; font-size: .8rem;
}
.collapse-toggle.open .toggle-icon { transform: rotate(180deg); }
.collapse-body {
    transition: grid-template-rows .3s ease;
    display: grid; grid-template-rows: 1fr;
}
.collapse-body > div { overflow: hidden; }
.filter-toggle {
    display: none; width: 100%; border: 2px solid var(--line); background: var(--paper);
    color: var(--ink); padding: 11px 14px; cursor: pointer;
    font: inherit; font-size: 13px; font-weight: 700; letter-spacing: .02em; text-transform: uppercase;
    align-items: center; justify-content: space-between;
    box-shadow: 4px 4px 0 var(--shadow);
}
.filter-toggle .toggle-icon {
    transition: transform .25s ease; display: inline-block; font-size: .8rem;
}
.filter-toggle.open .toggle-icon { transform: rotate(180deg); }
.filter-body {
    transition: grid-template-rows .3s ease;
    display: grid; grid-template-rows: 1fr;
}
.filter-body > div { overflow: hidden; }
.filter-body.collapsed { grid-template-rows: 0fr; }
/* --- Link icons (external-link arrow) --- */
.refs a::before {
    content: ''; width: 12px; height: 12px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%234272d7' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><path d='M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6'/><polyline points='15 3 21 3 21 9'/><line x1='10' y1='14' x2='21' y2='3'/></svg>") no-repeat center / contain;
}
/* Distilled study guides — a paper we have written up ourselves, not an outside link. */
.refs a.distilled { border-color: var(--blue); background: var(--tint-blue); color: var(--ink); }
.refs a.distilled:hover { background: #dbe9f7; }
.refs a.distilled::before {
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%234272d7' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><path d='M2 3h6a4 4 0 0 1 4 4v14a3 3 0 0 0-3-3H2z'/><path d='M22 3h-6a4 4 0 0 0-4 4v14a3 3 0 0 1 3-3h7z'/></svg>") no-repeat center / contain;
}
.side-panel a { display: inline-flex; align-items: center; gap: 5px; }
.side-panel a::before {
    content: ''; width: 13px; height: 13px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%234272d7' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><path d='M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6'/><polyline points='15 3 21 3 21 9'/><line x1='10' y1='14' x2='21' y2='3'/></svg>") no-repeat center / contain;
}
/* --- Button icons (contextual per type) --- */
.btn::before {
    content: ''; width: 14px; height: 14px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%2335312a' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><polyline points='1 4 1 10 7 10'/><path d='M3.51 15a9 9 0 1 0 2.13-9.36L1 10'/></svg>") no-repeat center / contain;
}
.filter-toggle > span:first-child,
.collapse-toggle > span:first-child { display: inline-flex; align-items: center; gap: 6px; }
.filter-toggle > span:first-child::before {
    content: ''; width: 14px; height: 14px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%2335312a' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><polygon points='22 3 2 3 10 12.46 10 19 14 21 14 12.46 22 3'/></svg>") no-repeat center / contain;
}
.collapse-toggle > span:first-child::before {
    content: ''; width: 14px; height: 14px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%2335312a' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><circle cx='12' cy='12' r='10'/><polygon points='16.24 7.76 14.12 14.12 7.76 16.24 9.88 9.88 16.24 7.76'/></svg>") no-repeat center / contain;
}
.chip::before {
    content: ''; width: 12px; height: 12px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%238a8578' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><circle cx='12' cy='12' r='10'/><polyline points='12 6 12 12 16 14'/></svg>") no-repeat center / contain;
}
.chip.active::before, .chip:hover::before {
    background-image: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%2335312a' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><circle cx='12' cy='12' r='10'/><polyline points='12 6 12 12 16 14'/></svg>");
}
.ddia-chip::before {
    content: ''; width: 11px; height: 11px; flex-shrink: 0;
    background: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%2335312a' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'><path d='M19 21l-7-5-7 5V5a2 2 0 0 1 2-2h10a2 2 0 0 1 2 2z'/></svg>") no-repeat center / contain;
}
@media (max-width: 980px) {
    .stats { grid-template-columns: repeat(2, minmax(0,1fr)); }
    .controls { grid-template-columns: 1fr; }
    .layout { grid-template-columns: 1fr; }
    aside { position: static; max-height: none; overflow-y: visible; }
    .collapse-toggle { display: flex; }
    .collapse-body { grid-template-rows: 0fr; }
    .collapse-body.open { grid-template-rows: 1fr; }
    .filter-toggle { display: flex; }
    .filter-body { grid-template-rows: 0fr; }
    .filter-body.open { grid-template-rows: 1fr; }
}
@media (max-width: 640px) {
    .stats { grid-template-columns: 1fr; }
    .hero { padding-top: 34px; }
    .card-head { display: block; }
    .badge { display: inline-block; margin-top: 10px; }
    .timeline { padding-left: 24px; }
    .pin { left: -24px; }
}
@media print {
    body { background: white; color: #111; }
    .controls-wrap, aside { display: none; }
    .layout { display: block; }
    .milestone, .era-heading, .stat { box-shadow: none; background: white; color: #111; border-color: #ccc; }
    .era-heading span, .era-heading strong { color: #111; }
    .subtitle, .meta, .footer, .side-panel p { color: #333; }
    a { color: #0645ad; }
}
.nav-bar { display: flex; align-items: center; justify-content: flex-end; gap: 12px; padding: 10px 0; }
.chips-row { display: flex; align-items: flex-start; justify-content: space-between; gap: 16px; }
.chips-row .chips { flex: 1 1 auto; }
.chips-row .lang-switch { flex: 0 0 auto; padding-bottom: 14px; }
.lang-switch { display: inline-flex; align-items: center; gap: 8px; }
.lang-switch .globe { font-size: 1rem; }
.lang-select {
    width: auto; padding: 10px 34px;
    text-align: center; text-align-last: center;
    font-size: .9rem; font-weight: 700; cursor: pointer;
    -webkit-appearance: none; appearance: none;
    background: var(--paper) url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='%2335312a'><polygon points='5 9 19 9 12 16'/></svg>") no-repeat right 12px center / 10px;
}
@media (max-width: 980px) {
    .nav-bar { justify-content: space-between; }
    .nav-bar .filter-toggle { flex: 1; width: auto; }
}
@media (min-width: 981px) {
    /* The language switch is moved into .chips-row (below Reset filters) by JS,
       so the nav bar collapses to nothing on desktop. */
    .nav-bar { padding: 0; }
}
.skip-nav { position: absolute; left: -9999px; top: 0; z-index: 999; background: var(--band); color: #f6f4ed; padding: 12px 16px; border: 2px solid var(--line); font-weight: 700; text-decoration: none; }
.skip-nav:focus { left: 0; }
.btn:focus-visible, .chip:focus-visible, .ddia-chip:focus-visible,
.collapse-toggle:focus-visible, .filter-toggle:focus-visible { outline: 3px solid var(--blue); outline-offset: 3px; }
</style>
</head>
<body>
<a href="#main-content" class="skip-nav">Skip to content</a>
<header class="hero">
    <div class="wrapper">
        <div class="kicker">Data systems timeline · selected milestones</div>
        <h1>From centralized DBMSs to AI-native data systems</h1>
        <p class="subtitle">A visual chronology of major data-system breakthroughs from the 1960s–1970s through 2026, emphasizing key people, papers, software systems, companies, and the concrete problems each breakthrough solved.</p>
        <div class="stats" aria-label="Timeline statistics">
            <div class="stat"><strong>83</strong><span>milestones</span></div>
            <div class="stat"><strong>5</strong><span>historical eras</span></div>
            <div class="stat"><strong>25</strong><span>technical categories</span></div>
            <div class="stat"><strong>1960–2026</strong><span>coverage window</span></div>
        </div>
        <a class="star-cta" href="https://github.com/Data-System-School/data-system-timeline" target="_blank" rel="noopener noreferrer">
            <span class="star" aria-hidden="true">★</span>
            <span>Star this repo on GitHub</span>
        </a>
    </div>
</header>

<div class="controls-wrap">
    <div class="wrapper">
        <div class="nav-bar">
            <button class="filter-toggle" id="filterToggle" aria-expanded="false" aria-controls="filterBody">
                <span>Filters</span>
                <span class="toggle-icon">▼</span>
            </button>
            <div class="lang-switch">
                <span class="globe" aria-hidden="true">🌐</span>
                <select id="langSelect" class="select lang-select" aria-label="Language / 語言">
                    <option value="en">English</option>
                    <option value="zh">繁體中文</option>
                </select>
            </div>
        </div>
        <div class="filter-body" id="filterBody">
            <div>
                <div class="controls">
                    <input id="search" class="search" type="search" placeholder="Search: Codd, SQL, Hadoop, vector, transactions, cloud..." aria-label="Search timeline" />
                    <select id="category" class="select" aria-label="Filter by category">
                        <option value="all">All categories</option>
                        <option value="AI / Vector retrieval">AI / Vector retrieval</option><option value="Big data processing">Big data processing</option><option value="Change data capture">Change data capture</option><option value="Cloud data systems">Cloud data systems</option><option value="Commercialization">Commercialization</option><option value="Data architecture">Data architecture</option><option value="Data catalog">Data catalog</option><option value="Data engineering">Data engineering</option><option value="Data formats">Data formats</option><option value="Data governance">Data governance</option><option value="Data model">Data model</option><option value="Data warehouse / OLAP">Data warehouse / OLAP</option><option value="Distributed SQL">Distributed SQL</option><option value="Distributed storage">Distributed storage</option><option value="Distributed systems">Distributed systems</option><option value="Extensible DBMS">Extensible DBMS</option><option value="Lakehouse">Lakehouse</option><option value="Operational DBMS">Operational DBMS</option><option value="Parallel DBMS">Parallel DBMS</option><option value="Query processing">Query processing</option><option value="Storage engine">Storage engine</option><option value="Streaming">Streaming</option><option value="Time-series">Time-series</option><option value="Transactions">Transactions</option><option value="Web-scale systems">Web-scale systems</option>
                    </select>
                    <button id="reset" class="btn">Reset filters</button>
                </div>
                <div class="chips-row">
                    <div class="chips">
                        <button class="chip active" data-era-filter="all">All eras</button>
                        <button class="chip" data-era-filter="1960s–1970s">1960s–1970s</button><button class="chip" data-era-filter="1980s–1990s">1980s–1990s</button><button class="chip" data-era-filter="2000s">2000s</button><button class="chip" data-era-filter="2010s">2010s</button><button class="chip" data-era-filter="2020–2026">2020–2026</button>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

<main id="main-content" class="wrapper layout">
    <aside>
        <button class="collapse-toggle" id="sidebarToggle" aria-expanded="false" aria-controls="sidebarBody">
            <span>Timeline guide</span>
            <span class="toggle-icon">&#9660;</span>
        </button>
        <div class="collapse-body" id="sidebarBody">
            <div>
                <div class="side-panel">
                    <h2 style="margin-top:20px;">How to read the timeline</h2>
                    <p>Each card names the breakthrough, the people or organizations behind it, the problem it solved, and why that solution changed the data-system landscape.</p>
                    <p>Each card cross-references chapters from Martin Kleppmann's <a href="https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/" target="_blank" rel="noopener noreferrer"><em>Designing Data-Intensive Applications</em></a> (2nd ed., 2025). Click the chapter chips on any card to see why that milestone connects to the chapter's concepts.</p>
                    <div class="phase-map">
                        <div class="phase"><b>1960s–1970s</b><span>Centralized operational data, DBMSs, relational model</span></div>
                        <div class="phase"><b>1980s–1990s</b><span>SQL standardization, transactions, recovery, warehouses</span></div>
                        <div class="phase"><b>2000s</b><span>Web-scale storage, NoSQL, Hadoop, cloud object storage</span></div>
                        <div class="phase"><b>2010s</b><span>Cloud warehouses, streaming, distributed SQL, orchestration</span></div>
                        <div class="phase"><b>2020–2026</b><span>Lakehouse reliability, vector retrieval, AI/agent data access</span></div>
                    </div>
                    <h2 style="margin-top:20px;">Category density</h2>
                    <ul class="cat-list"><li><span>AI / Vector retrieval</span><strong>8</strong></li><li><span>Query processing</span><strong>6</strong></li><li><span>Big data processing</span><strong>5</strong></li><li><span>Cloud data systems</span><strong>5</strong></li><li><span>Distributed systems</span><strong>5</strong></li><li><span>Data warehouse / OLAP</span><strong>4</strong></li><li><span>Distributed SQL</span><strong>4</strong></li><li><span>Operational DBMS</span><strong>4</strong></li><li><span>Commercialization</span><strong>3</strong></li><li><span>Data engineering</span><strong>3</strong></li><li><span>Data model</span><strong>3</strong></li><li><span>Distributed storage</span><strong>3</strong></li><li><span>Storage engine</span><strong>3</strong></li><li><span>Streaming</span><strong>3</strong></li><li><span>Data formats</span><strong>2</strong></li><li><span>Transactions</span><strong>2</strong></li><li><span>Web-scale systems</span><strong>2</strong></li><li><span>Change data capture</span><strong>1</strong></li><li><span>Data architecture</span><strong>1</strong></li><li><span>Data governance</span><strong>1</strong></li><li><span>Extensible DBMS</span><strong>1</strong></li><li><span>Lakehouse</span><strong>1</strong></li><li><span>Parallel DBMS</span><strong>1</strong></li><li><span>Time-series</span><strong>1</strong></li></ul>
                </div>
            </div>
        </div>
    </aside>
    <section>
        <div id="count" style="color:var(--muted); margin: 0 0 16px;" aria-live="polite"></div>
        <div id="noResults" class="no-results">No milestones match the current filters.</div>
        <section class="era-section" id="1960s-1970s" data-era-section="1960s–1970s"><div class="era-heading"><span>1960s–1970s</span><strong>9 milestones</strong></div><div class="timeline">
        <article class="milestone" data-era="1960s–1970s" data-category="Operational DBMS" data-search="1960–1964 sabre airline reservation system software / operational system operational dbms ibm + american airlines; c. r. smith and r. blair smith are central to the origin story airline reservations were slow, manual, and fragmented across offices and agents; inventory could not be updated reliably in real time. sabre centralized reservation inventory and made real-time operational data processing possible at business scale. a landmark oltp-style system that demonstrated large businesses could depend on centralized, always-current data infrastructure.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1960">1960–1964</time>
                    <h3>SABRE airline reservation system</h3>
                </div>
                <span class="badge">Operational DBMS</span>
            </div>
            <div class="meta"><span>software / operational system</span><span>IBM + American Airlines; C. R. Smith and R. Blair Smith are central to the origin story</span></div>
            <div class="problem"><strong>Problem solved:</strong> Airline reservations were slow, manual, and fragmented across offices and agents; inventory could not be updated reliably in real time.</div>
            <div class="solution"><strong>How it solved it:</strong> SABRE centralized reservation inventory and made real-time operational data processing possible at business scale.</div>
            <div class="impact"><strong>Why it mattered:</strong> A landmark OLTP-style system that demonstrated large businesses could depend on centralized, always-current data infrastructure.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.ibm.com/history/sabre" target="_blank" rel="noopener noreferrer">IBM History: SABRE</a> <a href="https://en.wikipedia.org/wiki/Sabre_(travel_reservation_system)" target="_blank" rel="noopener noreferrer">Wikipedia: Sabre</a> <a href="https://www.computerhistory.org/revolution/mainframe-computers/7/176/702" target="_blank" rel="noopener noreferrer">Computer History Museum: SABRE</a> <a href="https://ethw.org/SABRE_Airline_Reservation_System" target="_blank" rel="noopener noreferrer">Engineering &amp; Technology History Wiki</a> <a href="https://dl.acm.org/doi/10.1145/1460690.1460756" target="_blank" rel="noopener noreferrer">ACM: SABRE Electronic Reservations (1961)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="SABRE embodies the fundamental OLTP trade-off—an always-on operational system that shaped how we think about real-time data architectures.">Ch. 1: Data Systems Trade-offs</span><span class="ddia-chip" data-why="SABRE’s 24/7 reservation system required the reliability, performance, and scalability principles that define nonfunctional requirements.">Ch. 2: Nonfunctional Requirements</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Operational DBMS" data-search="1961–1964 integrated data store (ids) software / dbms operational dbms charles w. bachman, general electric application teams had to hand-code file navigation and record access for each program, creating brittle and duplicated data logic. ids treated the database as a managed shared resource and introduced direct-access database management concepts. widely cited as the first direct-access dbms; bachman later received the 1973 acm turing award for database contributions.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1961">1961–1964</time>
                    <h3>Integrated Data Store (IDS)</h3>
                </div>
                <span class="badge">Operational DBMS</span>
            </div>
            <div class="meta"><span>software / DBMS</span><span>Charles W. Bachman, General Electric</span></div>
            <div class="problem"><strong>Problem solved:</strong> Application teams had to hand-code file navigation and record access for each program, creating brittle and duplicated data logic.</div>
            <div class="solution"><strong>How it solved it:</strong> IDS treated the database as a managed shared resource and introduced direct-access database management concepts.</div>
            <div class="impact"><strong>Why it mattered:</strong> Widely cited as the first direct-access DBMS; Bachman later received the 1973 ACM Turing Award for database contributions.</div>
            <div class="refs"><strong>References:</strong> <a href="https://tschwarz.mscs.mu.edu/Classes/DB23/HW/bachmanIDS.pdf" target="_blank" rel="noopener noreferrer">Bachman IDS paper PDF</a> <a href="https://en.wikipedia.org/wiki/Charles_Bachman" target="_blank" rel="noopener noreferrer">Wikipedia: Charles Bachman</a> <a href="https://cacm.acm.org/opinion/how-charles-bachman-invented-the-dbms-a-foundation-of-our-digital-world/" target="_blank" rel="noopener noreferrer">CACM: How Bachman Invented the DBMS</a> <a href="https://amturing.acm.org/award_winners/bachman_9385610.cfm" target="_blank" rel="noopener noreferrer">ACM Turing Award: Bachman</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="IDS introduced the navigational data model—a precursor that the relational model was explicitly designed to replace.">Ch. 3: Data Models</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Operational DBMS" data-search="1966–1968 ibm information management system (ims) software / hierarchical dbms operational dbms ibm, nasa, north american rockwell apollo/saturn v engineering required huge hierarchical bills of material and engineering-change data that conventional files could not manage cleanly. ims provided a hierarchical dbms for mission-critical structured data and high-volume transaction workloads. proved dbmss could support mission-critical enterprise workloads and remains historically important in mainframe environments.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1966">1966–1968</time>
                    <h3>IBM Information Management System (IMS)</h3>
                </div>
                <span class="badge">Operational DBMS</span>
            </div>
            <div class="meta"><span>software / hierarchical DBMS</span><span>IBM, NASA, North American Rockwell</span></div>
            <div class="problem"><strong>Problem solved:</strong> Apollo/Saturn V engineering required huge hierarchical bills of material and engineering-change data that conventional files could not manage cleanly.</div>
            <div class="solution"><strong>How it solved it:</strong> IMS provided a hierarchical DBMS for mission-critical structured data and high-volume transaction workloads.</div>
            <div class="impact"><strong>Why it mattered:</strong> Proved DBMSs could support mission-critical enterprise workloads and remains historically important in mainframe environments.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.ibm.com/history/information-management-system" target="_blank" rel="noopener noreferrer">IBM History: IMS</a> <a href="https://en.wikipedia.org/wiki/IBM_Information_Management_System" target="_blank" rel="noopener noreferrer">Wikipedia: IBM IMS</a> <a href="https://twobithistory.org/2017/10/07/the-most-important-database.html" target="_blank" rel="noopener noreferrer">Two-Bit History: The Most Important Database</a> <a href="https://www.informit.com/articles/article.aspx?p=377307" target="_blank" rel="noopener noreferrer">InformIT: History of IMS at NASA</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="IMS’s hierarchical model is a key example of pre-relational data modeling, contrasted with relational and document approaches.">Ch. 3: Data Models</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Data model" data-search="1965–1971 codasyl dbtg network database model standard / model data model codasyl database task group; influenced by bachman’s navigational database ideas early database vendors and users lacked a common way to define schemas, subschemas, and database manipulation interfaces. codasyl specified a network-style data model and database definition/manipulation language concepts. standardized much of the pre-relational database worldview and shaped navigational database practice.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1965">1965–1971</time>
                    <h3>CODASYL DBTG network database model</h3>
                </div>
                <span class="badge">Data model</span>
            </div>
            <div class="meta"><span>standard / model</span><span>CODASYL Database Task Group; influenced by Bachman’s navigational database ideas</span></div>
            <div class="problem"><strong>Problem solved:</strong> Early database vendors and users lacked a common way to define schemas, subschemas, and database manipulation interfaces.</div>
            <div class="solution"><strong>How it solved it:</strong> CODASYL specified a network-style data model and database definition/manipulation language concepts.</div>
            <div class="impact"><strong>Why it mattered:</strong> Standardized much of the pre-relational database worldview and shaped navigational database practice.</div>
            <div class="refs"><strong>References:</strong> <a href="https://scispace.com/papers/data-base-task-group-report-to-the-codasyl-programming-it3vdc1zr6" target="_blank" rel="noopener noreferrer">CODASYL DBTG report record</a> <a href="https://en.wikipedia.org/wiki/CODASYL" target="_blank" rel="noopener noreferrer">Wikipedia: CODASYL</a> <a href="https://en.wikipedia.org/wiki/Network_model" target="_blank" rel="noopener noreferrer">Wikipedia: Network model</a> <a href="https://cacm.acm.org/opinion/how-charles-bachman-invented-the-dbms-a-foundation-of-our-digital-world/" target="_blank" rel="noopener noreferrer">CACM: Bachman and CODASYL standardization</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="The CODASYL network model is directly compared with the relational model to illustrate fundamental data modeling trade-offs.">Ch. 3: Data Models</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Data model" data-search="1970 relational model paper / model data model edgar f. codd, ibm users had to navigate physical record links; applications were tightly coupled to access paths and storage details. codd proposed representing data as relations/tables and using formal logic so users specify what they want, not how to traverse records. established logical data independence, declarative querying, and the foundation for sql databases.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1970">1970</time>
                    <h3>Relational model</h3>
                </div>
                <span class="badge">Data model</span>
            </div>
            <div class="meta"><span>paper / model</span><span>Edgar F. Codd, IBM</span></div>
            <div class="problem"><strong>Problem solved:</strong> Users had to navigate physical record links; applications were tightly coupled to access paths and storage details.</div>
            <div class="solution"><strong>How it solved it:</strong> Codd proposed representing data as relations/tables and using formal logic so users specify what they want, not how to traverse records.</div>
            <div class="impact"><strong>Why it mattered:</strong> Established logical data independence, declarative querying, and the foundation for SQL databases.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/relational-model.html" target="_blank" rel="noopener noreferrer">Codd 1970 paper, distilled</a> <a href="https://dl.acm.org/doi/10.1145/362384.362685" target="_blank" rel="noopener noreferrer">ACM: A Relational Model of Data (1970)</a> <a href="https://en.wikipedia.org/wiki/Edgar_F._Codd" target="_blank" rel="noopener noreferrer">Wikipedia: Edgar F. Codd</a> <a href="https://twobithistory.org/2017/12/29/codd-relational-model.html" target="_blank" rel="noopener noreferrer">Two-Bit History: Codd and the Relational Model</a> <a href="https://amturing.acm.org/award_winners/codd_1000892.cfm" target="_blank" rel="noopener noreferrer">ACM Turing Award: Codd</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Codd’s relational model is the foundational data model around which this entire chapter is organized.">Ch. 3: Data Models</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Storage engine" data-search="1970–1972 b-tree paper / storage structure storage engine rudolf bayer and edward m. mccreight, boeing scientific research labs sequential and hash-based indexes could not support efficient range queries, ordered traversals, and dynamic insertions on disk storage. b-trees organized keys in balanced, fan-out-optimized tree nodes that minimized disk seeks for point lookups and range scans. became the dominant on-disk index structure for nearly every relational database, file system, and storage engine for decades.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1970">1970–1972</time>
                    <h3>B-tree</h3>
                </div>
                <span class="badge">Storage engine</span>
            </div>
            <div class="meta"><span>paper / storage structure</span><span>Rudolf Bayer and Edward M. McCreight, Boeing Scientific Research Labs</span></div>
            <div class="problem"><strong>Problem solved:</strong> Sequential and hash-based indexes could not support efficient range queries, ordered traversals, and dynamic insertions on disk storage.</div>
            <div class="solution"><strong>How it solved it:</strong> B-trees organized keys in balanced, fan-out-optimized tree nodes that minimized disk seeks for point lookups and range scans.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became the dominant on-disk index structure for nearly every relational database, file system, and storage engine for decades.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/btree.html" target="_blank" rel="noopener noreferrer">B-tree paper, distilled</a> <a href="https://dl.acm.org/doi/10.1145/1734663.1734671" target="_blank" rel="noopener noreferrer">ACM: Organization and Maintenance of Large Ordered Indexes (1972)</a> <a href="https://en.wikipedia.org/wiki/B-tree" target="_blank" rel="noopener noreferrer">Wikipedia: B-tree</a> <a href="https://www.cs.cornell.edu/courses/cs3110/2012sp/recitations/rec25-B-trees/rec25.html" target="_blank" rel="noopener noreferrer">Cornell: B-trees explained</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="The B-tree is the primary index structure contrasted with LSM-trees, forming the core trade-off analysis of this chapter.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Query processing" data-search="1972–1976 ingres research system software / research dbms query processing michael stonebraker, eugene wong, uc berkeley the relational model was elegant, but skeptics questioned whether relational databases could be practical and performant. ingres implemented a working relational dbms and query language for real users and research workloads. influenced commercial relational systems and the lineage that eventually produced postgresql.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1972">1972–1976</time>
                    <h3>INGRES research system</h3>
                </div>
                <span class="badge">Query processing</span>
            </div>
            <div class="meta"><span>software / research DBMS</span><span>Michael Stonebraker, Eugene Wong, UC Berkeley</span></div>
            <div class="problem"><strong>Problem solved:</strong> The relational model was elegant, but skeptics questioned whether relational databases could be practical and performant.</div>
            <div class="solution"><strong>How it solved it:</strong> INGRES implemented a working relational DBMS and query language for real users and research workloads.</div>
            <div class="impact"><strong>Why it mattered:</strong> Influenced commercial relational systems and the lineage that eventually produced PostgreSQL.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/ingres.html" target="_blank" rel="noopener noreferrer">Stonebraker: Retrospection on INGRES (1980), distilled</a> <a href="https://dl.acm.org/doi/10.1145/320473.320476" target="_blank" rel="noopener noreferrer">ACM TODS: Design of INGRES (1976)</a> <a href="https://en.wikipedia.org/wiki/Ingres_(database)" target="_blank" rel="noopener noreferrer">Wikipedia: Ingres</a> <a href="https://dbdb.io/db/ingres" target="_blank" rel="noopener noreferrer">Database of Databases: Ingres</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="INGRES pioneered relational query language research, contributing to the declarative query paradigm discussed here.">Ch. 3: Data Models</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Query processing" data-search="1974–1979 ibm system r, sequel/sql, and cost-based optimization software / papers query processing ibm san jose; donald chamberlin, raymond boyce, patricia selinger, and colleagues declarative relational queries needed to be translated automatically into efficient physical access plans. system r developed sql-style querying and a cost-based optimizer that selected access paths and join plans. made relational querying practical and created the optimizer architecture used by modern sql systems.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1974">1974–1979</time>
                    <h3>IBM System R, SEQUEL/SQL, and cost-based optimization</h3>
                </div>
                <span class="badge">Query processing</span>
            </div>
            <div class="meta"><span>software / papers</span><span>IBM San Jose; Donald Chamberlin, Raymond Boyce, Patricia Selinger, and colleagues</span></div>
            <div class="problem"><strong>Problem solved:</strong> Declarative relational queries needed to be translated automatically into efficient physical access plans.</div>
            <div class="solution"><strong>How it solved it:</strong> System R developed SQL-style querying and a cost-based optimizer that selected access paths and join plans.</div>
            <div class="impact"><strong>Why it mattered:</strong> Made relational querying practical and created the optimizer architecture used by modern SQL systems.</div>
            <div class="refs"><strong>References:</strong> <a href="https://research.ibm.com/publications/access-path-selection-in-a-relational-database-management-system" target="_blank" rel="noopener noreferrer">Selinger et al. access-path selection</a> <a href="https://en.wikipedia.org/wiki/IBM_System_R" target="_blank" rel="noopener noreferrer">Wikipedia: IBM System R</a> <a href="https://dl.acm.org/doi/10.1145/320455.320457" target="_blank" rel="noopener noreferrer">ACM TODS: System R Relational Approach (1976)</a> <a href="https://dl.acm.org/doi/10.1145/358769.358784" target="_blank" rel="noopener noreferrer">ACM CACM: History of System R (1981)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="System R’s SQL became the dominant relational query language, shaping how we declare and interact with data models.">Ch. 3: Data Models</span><span class="ddia-chip" data-why="System R’s cost-based query optimizer pioneered the access-path selection techniques central to efficient storage and retrieval.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1960s–1970s" data-category="Commercialization" data-search="1979 oracle version 2 company / commercial dbms commercialization relational software inc. / oracle; larry ellison, bob miner, ed oates relational databases and sql were still largely research or laboratory ideas; enterprises needed purchasable products. oracle v2 commercialized sql relational database technology. helped move relational databases into mainstream enterprise software markets.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1979">1979</time>
                    <h3>Oracle Version 2</h3>
                </div>
                <span class="badge">Commercialization</span>
            </div>
            <div class="meta"><span>company / commercial DBMS</span><span>Relational Software Inc. / Oracle; Larry Ellison, Bob Miner, Ed Oates</span></div>
            <div class="problem"><strong>Problem solved:</strong> Relational databases and SQL were still largely research or laboratory ideas; enterprises needed purchasable products.</div>
            <div class="solution"><strong>How it solved it:</strong> Oracle V2 commercialized SQL relational database technology.</div>
            <div class="impact"><strong>Why it mattered:</strong> Helped move relational databases into mainstream enterprise software markets.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.oracle.com/database/50-years-relational-database/" target="_blank" rel="noopener noreferrer">Oracle: 50 years of relational database</a> <a href="https://en.wikipedia.org/wiki/Oracle_Database" target="_blank" rel="noopener noreferrer">Wikipedia: Oracle Database</a> <a href="https://en.wikipedia.org/wiki/Oracle_Corporation" target="_blank" rel="noopener noreferrer">Wikipedia: Oracle Corporation</a> <a href="https://www.britannica.com/money/Oracle-Corporation" target="_blank" rel="noopener noreferrer">Britannica: Oracle Corporation</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Oracle’s commercialization illustrates the trade-off between research prototypes and production-ready data systems.">Ch. 1: Data Systems Trade-offs</span><span class="ddia-chip" data-why="Oracle brought the relational model from research labs into commercial production, validating it at scale.">Ch. 3: Data Models</span></div>
        </article>
        </div></section><section class="era-section" id="1980s-1990s" data-era-section="1980s–1990s"><div class="era-heading"><span>1980s–1990s</span><strong>12 milestones</strong></div><div class="timeline">
        <article class="milestone" data-era="1980s–1990s" data-category="Transactions" data-search="late 1970s–1980s transaction processing theory and acid systems papers / systems theory transactions jim gray and collaborators concurrent users and crashes made database updates unsafe: partial writes, lost updates, dirty reads, and inconsistent state were common risks. transaction processing theory formalized atomicity, consistency, isolation, durability, commit protocols, locking, and recovery. created the correctness foundation for enterprise oltp, banking, reservations, inventory, and other mission-critical systems.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1970">Late 1970s–1980s</time>
                    <h3>Transaction processing theory and ACID systems</h3>
                </div>
                <span class="badge">Transactions</span>
            </div>
            <div class="meta"><span>papers / systems theory</span><span>Jim Gray and collaborators</span></div>
            <div class="problem"><strong>Problem solved:</strong> Concurrent users and crashes made database updates unsafe: partial writes, lost updates, dirty reads, and inconsistent state were common risks.</div>
            <div class="solution"><strong>How it solved it:</strong> Transaction processing theory formalized atomicity, consistency, isolation, durability, commit protocols, locking, and recovery.</div>
            <div class="impact"><strong>Why it mattered:</strong> Created the correctness foundation for enterprise OLTP, banking, reservations, inventory, and other mission-critical systems.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/transaction-survey.html" target="_blank" rel="noopener noreferrer">Eight Transaction Papers by Jim Gray, distilled</a> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/transaction-concept.html" target="_blank" rel="noopener noreferrer">Gray: The Transaction Concept (1981), distilled</a> <a href="https://en.wikipedia.org/wiki/ACID" target="_blank" rel="noopener noreferrer">Wikipedia: ACID</a> <a href="https://amturing.acm.org/award_winners/gray_3649936.cfm" target="_blank" rel="noopener noreferrer">ACM Turing Award: Jim Gray</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="This chapter is built around the ACID transaction guarantees that these foundational systems formalized.">Ch. 8: Transactions</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Commercialization" data-search="1983 ibm db2 software / commercial dbms commercialization ibm large ibm mainframe customers needed a production-grade relational database with sql support for enterprise workloads. db2 brought relational data management and sql to ibm’s mission-critical enterprise platform. accelerated relational database adoption in large organizations.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1983">1983</time>
                    <h3>IBM Db2</h3>
                </div>
                <span class="badge">Commercialization</span>
            </div>
            <div class="meta"><span>software / commercial DBMS</span><span>IBM</span></div>
            <div class="problem"><strong>Problem solved:</strong> Large IBM mainframe customers needed a production-grade relational database with SQL support for enterprise workloads.</div>
            <div class="solution"><strong>How it solved it:</strong> Db2 brought relational data management and SQL to IBM’s mission-critical enterprise platform.</div>
            <div class="impact"><strong>Why it mattered:</strong> Accelerated relational database adoption in large organizations.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.ibm.com/new/announcements/celebrating-30-years-of-db2-running-the-worlds-mission-critical-workloads" target="_blank" rel="noopener noreferrer">IBM: 30 years of Db2</a> <a href="https://en.wikipedia.org/wiki/IBM_Db2" target="_blank" rel="noopener noreferrer">Wikipedia: IBM Db2</a> <a href="https://www.ibm.com/blog/the-hidden-history-of-db2/" target="_blank" rel="noopener noreferrer">IBM Blog: The Hidden History of Db2</a> <a href="https://dl.acm.org/doi/10.1109/MAHC.2012.55" target="_blank" rel="noopener noreferrer">IEEE Annals: History and Growth of DB2</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Db2 established the relational model as the enterprise standard for mission-critical structured data.">Ch. 3: Data Models</span><span class="ddia-chip" data-why="Db2’s strong transaction guarantees exemplify the ACID properties and isolation levels analyzed here.">Ch. 8: Transactions</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Data warehouse / OLAP" data-search="1984 teradata dbc/1012 company / mpp database computer data warehouse / olap teradata a single machine could not economically scan and analyze very large business datasets. teradata combined database software with parallel hardware in a massively parallel database computer. helped establish mpp data warehousing for large-scale analytical workloads.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1984">1984</time>
                    <h3>Teradata DBC/1012</h3>
                </div>
                <span class="badge">Data warehouse / OLAP</span>
            </div>
            <div class="meta"><span>company / MPP database computer</span><span>Teradata</span></div>
            <div class="problem"><strong>Problem solved:</strong> A single machine could not economically scan and analyze very large business datasets.</div>
            <div class="solution"><strong>How it solved it:</strong> Teradata combined database software with parallel hardware in a massively parallel database computer.</div>
            <div class="impact"><strong>Why it mattered:</strong> Helped establish MPP data warehousing for large-scale analytical workloads.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.computerhistory.org/collections/catalog/102621859/" target="_blank" rel="noopener noreferrer">Computer History Museum: DBC/1012</a> <a href="https://en.wikipedia.org/wiki/DBC_1012" target="_blank" rel="noopener noreferrer">Wikipedia: DBC/1012</a> <a href="https://en.wikipedia.org/wiki/Teradata" target="_blank" rel="noopener noreferrer">Wikipedia: Teradata</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Teradata pioneered the shared-nothing partitioning architecture for massively parallel analytical query processing.">Ch. 7: Sharding</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Query processing" data-search="1986 ansi sql standard standard query processing ansi x3h2 committee and sql vendors sql dialect fragmentation made it hard for users and tools to move across relational database vendors. the ansi sql standard defined a common language baseline for relational querying. improved portability, education, procurement, and ecosystem growth for relational databases.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1986">1986</time>
                    <h3>ANSI SQL standard</h3>
                </div>
                <span class="badge">Query processing</span>
            </div>
            <div class="meta"><span>standard</span><span>ANSI X3H2 committee and SQL vendors</span></div>
            <div class="problem"><strong>Problem solved:</strong> SQL dialect fragmentation made it hard for users and tools to move across relational database vendors.</div>
            <div class="solution"><strong>How it solved it:</strong> The ANSI SQL standard defined a common language baseline for relational querying.</div>
            <div class="impact"><strong>Why it mattered:</strong> Improved portability, education, procurement, and ecosystem growth for relational databases.</div>
            <div class="refs"><strong>References:</strong> <a href="https://blog.ansi.org/ansi/sql-standard-iso-iec-9075-2023-ansi-x3-135/" target="_blank" rel="noopener noreferrer">ANSI SQL standard overview</a> <a href="https://en.wikipedia.org/wiki/SQL" target="_blank" rel="noopener noreferrer">Wikipedia: SQL</a> <a href="https://en.wikipedia.org/wiki/ISO/IEC_9075" target="_blank" rel="noopener noreferrer">Wikipedia: ISO/IEC 9075</a> <a href="https://learnsql.com/blog/history-of-sql-standards/" target="_blank" rel="noopener noreferrer">LearnSQL: History of SQL Standards</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="SQL standardization codified the declarative query language interface for relational data models.">Ch. 3: Data Models</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Extensible DBMS" data-search="1986 onward postgres software / research dbms extensible dbms michael stonebraker, uc berkeley first-generation relational systems had rigid scalar types and limited support for complex application-specific objects and operators. postgres introduced object-relational extensibility, user-defined types/operators, and rules. became the intellectual ancestor of postgresql and influenced extensible database architecture.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1986">1986 onward</time>
                    <h3>POSTGRES</h3>
                </div>
                <span class="badge">Extensible DBMS</span>
            </div>
            <div class="meta"><span>software / research DBMS</span><span>Michael Stonebraker, UC Berkeley</span></div>
            <div class="problem"><strong>Problem solved:</strong> First-generation relational systems had rigid scalar types and limited support for complex application-specific objects and operators.</div>
            <div class="solution"><strong>How it solved it:</strong> POSTGRES introduced object-relational extensibility, user-defined types/operators, and rules.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became the intellectual ancestor of PostgreSQL and influenced extensible database architecture.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/postgres.html" target="_blank" rel="noopener noreferrer">Stonebraker: Looking Back at Postgres (2019), distilled</a> <a href="https://www.postgresql.org/docs/current/history.html" target="_blank" rel="noopener noreferrer">PostgreSQL history</a> <a href="https://en.wikipedia.org/wiki/PostgreSQL" target="_blank" rel="noopener noreferrer">Wikipedia: PostgreSQL</a> <a href="https://dl.acm.org/doi/10.1145/16894.16888" target="_blank" rel="noopener noreferrer">ACM SIGMOD: The Design of POSTGRES (1986)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="POSTGRES’s extensible type system pushed data models beyond rigid relational schemas with user-defined types.">Ch. 3: Data Models</span><span class="ddia-chip" data-why="POSTGRES explored novel storage approaches including its append-only, log-structured storage engine design.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Parallel DBMS" data-search="1986–1990s gamma and shared-nothing parallel db research paper / research system parallel dbms david dewitt and university of wisconsin database group relational query execution needed to scale beyond a single server without centralized bottlenecks. gamma showed how data partitioning and parallel relational operators could run on shared-nothing architectures. influenced parallel databases, mpp warehouses, and later distributed analytical engines.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1986">1986–1990s</time>
                    <h3>Gamma and shared-nothing parallel DB research</h3>
                </div>
                <span class="badge">Parallel DBMS</span>
            </div>
            <div class="meta"><span>paper / research system</span><span>David DeWitt and University of Wisconsin database group</span></div>
            <div class="problem"><strong>Problem solved:</strong> Relational query execution needed to scale beyond a single server without centralized bottlenecks.</div>
            <div class="solution"><strong>How it solved it:</strong> Gamma showed how data partitioning and parallel relational operators could run on shared-nothing architectures.</div>
            <div class="impact"><strong>Why it mattered:</strong> Influenced parallel databases, MPP warehouses, and later distributed analytical engines.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/gamma.html" target="_blank" rel="noopener noreferrer">Gamma shared-nothing paper, distilled</a> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/parallel-cacm.html" target="_blank" rel="noopener noreferrer">DeWitt &amp; Gray: Parallel Database Systems (CACM 1992), distilled</a> <a href="https://en.wikipedia.org/wiki/Shared-nothing_architecture" target="_blank" rel="noopener noreferrer">Wikipedia: Shared-nothing architecture</a> <a href="https://dl.acm.org/doi/10.1109/69.50905" target="_blank" rel="noopener noreferrer">IEEE TKDE: The Gamma Database Machine Project</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Gamma’s shared-nothing architecture is a foundational research reference for partitioned parallel database design.">Ch. 7: Sharding</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Transactions" data-search="1992 aries recovery algorithm paper / recovery design transactions c. mohan and ibm collaborators databases needed fast, correct recovery after crashes while supporting fine-grained locking and high concurrency. aries used write-ahead logging, repeating history during redo, and logical undo for robust crash recovery. became one of the most influential recovery algorithms in commercial database systems.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1992">1992</time>
                    <h3>ARIES recovery algorithm</h3>
                </div>
                <span class="badge">Transactions</span>
            </div>
            <div class="meta"><span>paper / recovery design</span><span>C. Mohan and IBM collaborators</span></div>
            <div class="problem"><strong>Problem solved:</strong> Databases needed fast, correct recovery after crashes while supporting fine-grained locking and high concurrency.</div>
            <div class="solution"><strong>How it solved it:</strong> ARIES used write-ahead logging, repeating history during redo, and logical undo for robust crash recovery.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became one of the most influential recovery algorithms in commercial database systems.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/aries.html" target="_blank" rel="noopener noreferrer">ARIES paper, distilled</a> <a href="https://en.wikipedia.org/wiki/Algorithms_for_Recovery_and_Isolation_Exploiting_Semantics" target="_blank" rel="noopener noreferrer">Wikipedia: ARIES</a> <a href="https://dl.acm.org/doi/10.1145/128765.128770" target="_blank" rel="noopener noreferrer">ACM TODS: ARIES (Mohan et al., 1992)</a> <a href="https://research.ibm.com/publications/aries-a-transaction-recovery-method-supporting-fine-granularity-locking-and-partial-rollbacks-using-write-ahead-logging" target="_blank" rel="noopener noreferrer">IBM Research: ARIES</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="ARIES defined write-ahead logging and crash recovery—techniques central to transaction durability guarantees.">Ch. 8: Transactions</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Data warehouse / OLAP" data-search="early–mid 1990s data warehouse architecture and dimensional modeling architecture / books data warehouse / olap bill inmon; ralph kimball operational databases were poor environments for long-term, historical, cross-functional business analysis. warehousing separated analytical data from oltp and dimensional modeling made metrics, facts, and dimensions easier to query. created the standard enterprise bi architecture for decades.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1990">Early–mid 1990s</time>
                    <h3>Data warehouse architecture and dimensional modeling</h3>
                </div>
                <span class="badge">Data warehouse / OLAP</span>
            </div>
            <div class="meta"><span>architecture / books</span><span>Bill Inmon; Ralph Kimball</span></div>
            <div class="problem"><strong>Problem solved:</strong> Operational databases were poor environments for long-term, historical, cross-functional business analysis.</div>
            <div class="solution"><strong>How it solved it:</strong> Warehousing separated analytical data from OLTP and dimensional modeling made metrics, facts, and dimensions easier to query.</div>
            <div class="impact"><strong>Why it mattered:</strong> Created the standard enterprise BI architecture for decades.</div>
            <div class="refs"><strong>References:</strong> <a href="https://books.google.com/books/about/Building_the_Data_Warehouse.html?id=duRQAAAAMAAJ" target="_blank" rel="noopener noreferrer">Inmon, Building the Data Warehouse</a> <a href="https://en.wikipedia.org/wiki/Bill_Inmon" target="_blank" rel="noopener noreferrer">Wikipedia: Bill Inmon</a> <a href="https://en.wikipedia.org/wiki/Dimensional_modeling" target="_blank" rel="noopener noreferrer">Wikipedia: Dimensional modeling</a> <a href="https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/" target="_blank" rel="noopener noreferrer">Kimball Group: Dimensional Modeling Techniques</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="The data warehouse exemplifies the fundamental OLTP/OLAP architectural split in data systems design.">Ch. 1: Data Systems Trade-offs</span><span class="ddia-chip" data-why="Star schemas and column-oriented storage for analytical queries are covered extensively in this chapter.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Commercialization" data-search="1995–1996 mysql and postgresql open-source relational systems software / open source commercialization mysql ab founders michael “monty” widenius, david axmark, allan larsson; postgresql community developers and web companies needed affordable, accessible sql databases without expensive enterprise licensing. open-source relational systems made production sql databases widely available to websites, startups, and later cloud services. became foundational to the web era and modern open-source database ecosystem.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1995">1995–1996</time>
                    <h3>MySQL and PostgreSQL open-source relational systems</h3>
                </div>
                <span class="badge">Commercialization</span>
            </div>
            <div class="meta"><span>software / open source</span><span>MySQL AB founders Michael “Monty” Widenius, David Axmark, Allan Larsson; PostgreSQL community</span></div>
            <div class="problem"><strong>Problem solved:</strong> Developers and web companies needed affordable, accessible SQL databases without expensive enterprise licensing.</div>
            <div class="solution"><strong>How it solved it:</strong> Open-source relational systems made production SQL databases widely available to websites, startups, and later cloud services.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became foundational to the web era and modern open-source database ecosystem.</div>
            <div class="refs"><strong>References:</strong> <a href="https://blogs.oracle.com/mysql/mysql-retrospective-the-early-years" target="_blank" rel="noopener noreferrer">MySQL retrospective</a> <a href="https://www.postgresql.org/docs/current/history.html" target="_blank" rel="noopener noreferrer">PostgreSQL history</a> <a href="https://en.wikipedia.org/wiki/MySQL" target="_blank" rel="noopener noreferrer">Wikipedia: MySQL</a> <a href="https://dev.mysql.com/doc/refman/8.0/en/history.html" target="_blank" rel="noopener noreferrer">MySQL Reference Manual: History</a> <a href="https://www.postgresql.org/about/" target="_blank" rel="noopener noreferrer">PostgreSQL: About</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Both systems implement the relational model with different design philosophies and extension points.">Ch. 3: Data Models</span><span class="ddia-chip" data-why="Their contrasting storage engines (InnoDB B-tree vs. PostgreSQL heap) illustrate key storage design trade-offs.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Data warehouse / OLAP" data-search="1995–1997 data cube and olap relational aggregation paper / query operator data warehouse / olap jim gray, surajit chaudhuri, adam bosworth, andrew layman, hamid pirahesh, and collaborators sql group by was too limited for multidimensional roll-up, drill-down, subtotals, and cross-tabs. the cube operator generalized aggregation for multidimensional olap queries. influenced sql extensions, olap engines, and business-intelligence query semantics.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1995">1995–1997</time>
                    <h3>Data Cube and OLAP relational aggregation</h3>
                </div>
                <span class="badge">Data warehouse / OLAP</span>
            </div>
            <div class="meta"><span>paper / query operator</span><span>Jim Gray, Surajit Chaudhuri, Adam Bosworth, Andrew Layman, Hamid Pirahesh, and collaborators</span></div>
            <div class="problem"><strong>Problem solved:</strong> SQL GROUP BY was too limited for multidimensional roll-up, drill-down, subtotals, and cross-tabs.</div>
            <div class="solution"><strong>How it solved it:</strong> The cube operator generalized aggregation for multidimensional OLAP queries.</div>
            <div class="impact"><strong>Why it mattered:</strong> Influenced SQL extensions, OLAP engines, and business-intelligence query semantics.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/data-cube.html" target="_blank" rel="noopener noreferrer">Data Cube paper, distilled</a> <a href="https://en.wikipedia.org/wiki/Data_cube" target="_blank" rel="noopener noreferrer">Wikipedia: Data cube</a> <a href="https://en.wikipedia.org/wiki/Online_analytical_processing" target="_blank" rel="noopener noreferrer">Wikipedia: Online analytical processing</a> <a href="https://dl.acm.org/doi/10.1145/253262.253335" target="_blank" rel="noopener noreferrer">ACM: Data Cube Relational Aggregation (1996)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="OLAP cubes and materialized aggregates are discussed as storage-level optimizations for analytical queries.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Storage engine" data-search="1996 log-structured merge tree (lsm-tree) paper / storage structure storage engine patrick o’neil, edward cheng, dieter gawlick, elizabeth o’neil traditional disk indexes were inefficient for high-write workloads because random in-place updates were expensive. lsm-trees batch writes in memory and merge sorted components over time, trading write efficiency against controlled read amplification. became foundational for bigtable, cassandra, hbase, leveldb, rocksdb, and many key-value stores.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1996">1996</time>
                    <h3>Log-Structured Merge Tree (LSM-tree)</h3>
                </div>
                <span class="badge">Storage engine</span>
            </div>
            <div class="meta"><span>paper / storage structure</span><span>Patrick O’Neil, Edward Cheng, Dieter Gawlick, Elizabeth O’Neil</span></div>
            <div class="problem"><strong>Problem solved:</strong> Traditional disk indexes were inefficient for high-write workloads because random in-place updates were expensive.</div>
            <div class="solution"><strong>How it solved it:</strong> LSM-trees batch writes in memory and merge sorted components over time, trading write efficiency against controlled read amplification.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became foundational for Bigtable, Cassandra, HBase, LevelDB, RocksDB, and many key-value stores.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/lsm-tree.html" target="_blank" rel="noopener noreferrer">LSM-tree paper, distilled</a> <a href="https://en.wikipedia.org/wiki/Log-structured_merge-tree" target="_blank" rel="noopener noreferrer">Wikipedia: Log-structured merge-tree</a> <a href="https://link.springer.com/article/10.1007/s002360050048" target="_blank" rel="noopener noreferrer">Springer: Original LSM-tree paper (Acta Informatica)</a> <a href="https://blog.acolyer.org/2014/11/26/the-log-structured-merge-tree-lsm-tree/" target="_blank" rel="noopener noreferrer">The Morning Paper: LSM-tree review</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="The LSM-tree is a core storage structure contrasted with B-trees, optimized for write-heavy workloads.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="1980s–1990s" data-category="Distributed systems" data-search="1989–2001 paxos consensus algorithm paper / consensus algorithm distributed systems leslie lamport replicated distributed systems needed machines to agree on state despite failures and message delays. paxos formalized fault-tolerant distributed consensus for replicated logs and state machines. became a foundation for metadata services, distributed databases, and coordination systems. the part-time parliament paxos made simple">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1989">1989–2001</time>
                    <h3>Paxos consensus algorithm</h3>
                </div>
                <span class="badge">Distributed systems</span>
            </div>
            <div class="meta"><span>paper / consensus algorithm</span><span>Leslie Lamport (original paper written 1989, published 1998; "Paxos Made Simple" 2001)</span></div>
            <div class="problem"><strong>Problem solved:</strong> Replicated distributed systems needed machines to agree on state despite failures and message delays.</div>
            <div class="solution"><strong>How it solved it:</strong> Paxos formalized fault-tolerant distributed consensus for replicated logs and state machines.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became a foundation for metadata services, distributed databases, and coordination systems.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/paxos-simple.html" target="_blank" rel="noopener noreferrer">Paxos Made Simple, distilled</a> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/paxos-parliament.html" target="_blank" rel="noopener noreferrer">Lamport: The Part-Time Parliament, distilled</a> <a href="https://en.wikipedia.org/wiki/Paxos_(computer_science)" target="_blank" rel="noopener noreferrer">Wikipedia: Paxos</a> <a href="https://dl.acm.org/doi/10.1145/279227.279229" target="_blank" rel="noopener noreferrer">ACM TOCS: The Part-Time Parliament (1998)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Paxos is the canonical consensus algorithm whose properties, limitations, and variants are analyzed in depth.">Ch. 10: Consistency & Consensus</span></div>
        </article>
        </div></section><section class="era-section" id="2000s" data-era-section="2000s"><div class="era-heading"><span>2000s</span><strong>18 milestones</strong></div><div class="timeline">
        <article class="milestone" data-era="2000s" data-category="Storage engine" data-search="1999–2004 apache lucene and solr software / search library storage engine doug cutting; later the apache lucene and solr communities relational and key-value stores were poor at full-text search: relevance ranking, tokenization, stemming, and fast keyword lookup over large document collections. lucene provided a high-performance inverted-index library with relevance scoring; solr wrapped it as a distributed, operable search server. became the open-source foundation of full-text search, later powering solr and elasticsearch and most enterprise search.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="1999">1999–2004</time>
                    <h3>Apache Lucene and Solr</h3>
                </div>
                <span class="badge">Storage engine</span>
            </div>
            <div class="meta"><span>software / search library</span><span>Doug Cutting; later the Apache Lucene and Solr communities</span></div>
            <div class="problem"><strong>Problem solved:</strong> Relational and key-value stores were poor at full-text search: relevance ranking, tokenization, stemming, and fast keyword lookup over large document collections.</div>
            <div class="solution"><strong>How it solved it:</strong> Lucene provided a high-performance inverted-index library with relevance scoring; Solr wrapped it as a distributed, operable search server.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became the open-source foundation of full-text search, later powering Solr and Elasticsearch and most enterprise search.</div>
            <div class="refs"><strong>References:</strong> <a href="https://lucene.apache.org/" target="_blank" rel="noopener noreferrer">Apache Lucene</a> <a href="https://solr.apache.org/" target="_blank" rel="noopener noreferrer">Apache Solr</a> <a href="https://en.wikipedia.org/wiki/Apache_Lucene" target="_blank" rel="noopener noreferrer">Wikipedia: Apache Lucene</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="DDIA Ch. 4 treats full-text search and inverted indexes as a distinct storage-and-retrieval structure, which Lucene pioneered in open source.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Operational DBMS" data-search="2000 sqlite software / embedded dbms operational dbms d. richard hipp applications needed a self-contained, serverless sql database that required zero configuration and zero administration. sqlite provided an embedded sql database engine stored in a single cross-platform file, requiring no separate server process. became the most widely deployed database engine in the world, embedded in billions of devices, browsers, and applications.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2000">2000</time>
                    <h3>SQLite</h3>
                </div>
                <span class="badge">Operational DBMS</span>
            </div>
            <div class="meta"><span>software / embedded DBMS</span><span>D. Richard Hipp</span></div>
            <div class="problem"><strong>Problem solved:</strong> Applications needed a self-contained, serverless SQL database that required zero configuration and zero administration.</div>
            <div class="solution"><strong>How it solved it:</strong> SQLite provided an embedded SQL database engine stored in a single cross-platform file, requiring no separate server process.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became the most widely deployed database engine in the world, embedded in billions of devices, browsers, and applications.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.sqlite.org/about.html" target="_blank" rel="noopener noreferrer">SQLite: About</a> <a href="https://en.wikipedia.org/wiki/SQLite" target="_blank" rel="noopener noreferrer">Wikipedia: SQLite</a> <a href="https://www.sqlite.org/arch.html" target="_blank" rel="noopener noreferrer">Architecture of SQLite</a> <a href="https://dl.acm.org/doi/10.14778/3554821.3554842" target="_blank" rel="noopener noreferrer">SQLite: Past, Present, and Future (VLDB 2022)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="SQLite's embedded architecture illustrates the trade-off between client-server and in-process data systems.">Ch. 1: Data Systems Trade-offs</span><span class="ddia-chip" data-why="SQLite uses a B-tree storage engine with WAL journaling, a classic storage and retrieval approach.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Distributed systems" data-search="2000–2002 cap theorem / brewer’s conjecture formalized theory / paper distributed systems eric brewer; seth gilbert and nancy lynch distributed-system designers needed a clear framework for the trade-offs caused by network partitions. cap clarified that under partition, systems must trade off consistency and availability. strongly shaped nosql and distributed database design debates in the 2000s and 2010s.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2000">2000–2002</time>
                    <h3>CAP theorem / Brewer’s conjecture formalized</h3>
                </div>
                <span class="badge">Distributed systems</span>
            </div>
            <div class="meta"><span>theory / paper</span><span>Eric Brewer; Seth Gilbert and Nancy Lynch</span></div>
            <div class="problem"><strong>Problem solved:</strong> Distributed-system designers needed a clear framework for the trade-offs caused by network partitions.</div>
            <div class="solution"><strong>How it solved it:</strong> CAP clarified that under partition, systems must trade off consistency and availability.</div>
            <div class="impact"><strong>Why it mattered:</strong> Strongly shaped NoSQL and distributed database design debates in the 2000s and 2010s.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/cap.html" target="_blank" rel="noopener noreferrer">Gilbert &amp; Lynch: Perspectives on the CAP Theorem, distilled</a> <a href="https://dl.acm.org/doi/10.1145/564585.564601" target="_blank" rel="noopener noreferrer">Gilbert &amp; Lynch CAP paper</a> <a href="https://en.wikipedia.org/wiki/CAP_theorem" target="_blank" rel="noopener noreferrer">Wikipedia: CAP theorem</a> <a href="https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf" target="_blank" rel="noopener noreferrer">Brewer: PODC 2000 keynote slides</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="CAP’s impossibility result arises directly from the unreliable networks and partial failures discussed here.">Ch. 9: Distributed Systems</span><span class="ddia-chip" data-why="The CAP theorem and PACELC framework shape the consistency–availability trade-off analysis in this chapter.">Ch. 10: Consistency & Consensus</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Web-scale systems" data-search="2003–2004 memcached software / distributed cache web-scale systems brad fitzpatrick, danga interactive / livejournal dynamic websites repeatedly hit databases for the same read-heavy data, overloading backing stores. memcached provided a simple distributed in-memory cache in front of databases and applications. became a standard web-scale architecture component for reducing database load and latency.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2003">2003–2004</time>
                    <h3>Memcached</h3>
                </div>
                <span class="badge">Web-scale systems</span>
            </div>
            <div class="meta"><span>software / distributed cache</span><span>Brad Fitzpatrick, Danga Interactive / LiveJournal</span></div>
            <div class="problem"><strong>Problem solved:</strong> Dynamic websites repeatedly hit databases for the same read-heavy data, overloading backing stores.</div>
            <div class="solution"><strong>How it solved it:</strong> Memcached provided a simple distributed in-memory cache in front of databases and applications.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became a standard web-scale architecture component for reducing database load and latency.</div>
            <div class="refs"><strong>References:</strong> <a href="https://www.linuxjournal.com/article/7451" target="_blank" rel="noopener noreferrer">Linux Journal: memcached</a> <a href="https://en.wikipedia.org/wiki/Memcached" target="_blank" rel="noopener noreferrer">Wikipedia: Memcached</a> <a href="https://memcached.org/" target="_blank" rel="noopener noreferrer">Memcached official site</a> <a href="https://github.com/memcached/memcached/wiki" target="_blank" rel="noopener noreferrer">Memcached GitHub Wiki</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Caching layers like Memcached address the performance and scalability requirements defined in this chapter.">Ch. 2: Nonfunctional Requirements</span><span class="ddia-chip" data-why="Distributed caches raise consistency challenges analogous to replication lag and stale reads.">Ch. 6: Replication</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Distributed storage" data-search="2003 google file system (gfs) paper / distributed storage distributed storage sanjay ghemawat, howard gobioff, shun-tak leung, google google needed fault-tolerant file storage for huge datasets on unreliable commodity servers. gfs optimized distributed storage for large files, sequential access, replication, and failure recovery. influenced hdfs and large-scale distributed storage design.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2003">2003</time>
                    <h3>Google File System (GFS)</h3>
                </div>
                <span class="badge">Distributed storage</span>
            </div>
            <div class="meta"><span>paper / distributed storage</span><span>Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung, Google</span></div>
            <div class="problem"><strong>Problem solved:</strong> Google needed fault-tolerant file storage for huge datasets on unreliable commodity servers.</div>
            <div class="solution"><strong>How it solved it:</strong> GFS optimized distributed storage for large files, sequential access, replication, and failure recovery.</div>
            <div class="impact"><strong>Why it mattered:</strong> Influenced HDFS and large-scale distributed storage design.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/gfs.html" target="_blank" rel="noopener noreferrer">GFS SOSP 2003 paper, distilled</a> <a href="https://research.google/pubs/the-google-file-system/" target="_blank" rel="noopener noreferrer">Google Research: GFS</a> <a href="https://en.wikipedia.org/wiki/Google_File_System" target="_blank" rel="noopener noreferrer">Wikipedia: Google File System</a> <a href="https://dl.acm.org/doi/10.1145/945445.945450" target="_blank" rel="noopener noreferrer">ACM: GFS (SOSP 2003)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="GFS uses single-leader replication with automatic failover for fault tolerance across commodity hardware.">Ch. 6: Replication</span><span class="ddia-chip" data-why="GFS distributes file chunks across servers, applying partitioning principles for parallel I/O throughput.">Ch. 7: Sharding</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Big data processing" data-search="2004 mapreduce paper / batch-compute system big data processing jeffrey dean, sanjay ghemawat, google writing reliable distributed batch jobs over huge datasets required manual scheduling, failure handling, and data distribution. mapreduce let developers write map and reduce functions while the runtime handled distribution, retries, and aggregation. defined the first mainstream big-data programming model and inspired hadoop mapreduce.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2004">2004</time>
                    <h3>MapReduce</h3>
                </div>
                <span class="badge">Big data processing</span>
            </div>
            <div class="meta"><span>paper / batch-compute system</span><span>Jeffrey Dean, Sanjay Ghemawat, Google</span></div>
            <div class="problem"><strong>Problem solved:</strong> Writing reliable distributed batch jobs over huge datasets required manual scheduling, failure handling, and data distribution.</div>
            <div class="solution"><strong>How it solved it:</strong> MapReduce let developers write map and reduce functions while the runtime handled distribution, retries, and aggregation.</div>
            <div class="impact"><strong>Why it mattered:</strong> Defined the first mainstream big-data programming model and inspired Hadoop MapReduce.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/mapreduce.html" target="_blank" rel="noopener noreferrer">MapReduce OSDI 2004 paper, distilled</a> <a href="https://www.usenix.org/conference/osdi-04/mapreduce-simplified-data-processing-large-clusters" target="_blank" rel="noopener noreferrer">OSDI 2004 MapReduce paper</a> <a href="https://en.wikipedia.org/wiki/MapReduce" target="_blank" rel="noopener noreferrer">Wikipedia: MapReduce</a> <a href="https://dl.acm.org/doi/10.1145/1327452.1327492" target="_blank" rel="noopener noreferrer">ACM CACM: MapReduce (2008)</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="MapReduce is the foundational batch processing paradigm that this entire chapter builds upon.">Ch. 11: Batch Processing</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Data warehouse / OLAP" data-search="2005 c-store and vertica-style column stores paper / commercial lineage data warehouse / olap michael stonebraker, daniel abadi, samuel madden, and collaborators; later vertica row stores wasted i/o for analytical queries that scanned a few columns across many rows. columnar storage improved compression, column pruning, vectorized scans, and analytical performance. influenced modern cloud warehouses and analytical engines.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2005">2005</time>
                    <h3>C-Store and Vertica-style column stores</h3>
                </div>
                <span class="badge">Data warehouse / OLAP</span>
            </div>
            <div class="meta"><span>paper / commercial lineage</span><span>Michael Stonebraker, Daniel Abadi, Samuel Madden, and collaborators; later Vertica</span></div>
            <div class="problem"><strong>Problem solved:</strong> Row stores wasted I/O for analytical queries that scanned a few columns across many rows.</div>
            <div class="solution"><strong>How it solved it:</strong> Columnar storage improved compression, column pruning, vectorized scans, and analytical performance.</div>
            <div class="impact"><strong>Why it mattered:</strong> Influenced modern cloud warehouses and analytical engines.</div>
            <div class="refs"><strong>References:</strong> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/vertica.html" target="_blank" rel="noopener noreferrer">Vertica paper, distilled</a> <a class="distilled" href="https://datasystem.school/data-system-papers-distilled/papers/cstore.html" target="_blank" rel="noopener noreferrer">C-Store VLDB 2005 paper, distilled</a> <a href="https://en.wikipedia.org/wiki/C-Store" target="_blank" rel="noopener noreferrer">Wikipedia: C-Store</a> <a href="https://en.wikipedia.org/wiki/Vertica" target="_blank" rel="noopener noreferrer">Wikipedia: Vertica</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="C-Store’s column-oriented storage is a central innovation in analytical data storage and retrieval.">Ch. 4: Storage & Retrieval</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Cloud data systems" data-search="2006 amazon s3 company / cloud storage cloud data systems amazon web services teams needed durable, scalable, api-accessible storage without buying or operating storage hardware. s3 provided low-cost object storage independent of local filesystems and databases. became a foundation for data lakes, cloud-native warehouses, and disaggregated storage/compute systems.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2006">2006</time>
                    <h3>Amazon S3</h3>
                </div>
                <span class="badge">Cloud data systems</span>
            </div>
            <div class="meta"><span>company / cloud storage</span><span>Amazon Web Services</span></div>
            <div class="problem"><strong>Problem solved:</strong> Teams needed durable, scalable, API-accessible storage without buying or operating storage hardware.</div>
            <div class="solution"><strong>How it solved it:</strong> S3 provided low-cost object storage independent of local filesystems and databases.</div>
            <div class="impact"><strong>Why it mattered:</strong> Became a foundation for data lakes, cloud-native warehouses, and disaggregated storage/compute systems.</div>
            <div class="refs"><strong>References:</strong> <a href="https://press.aboutamazon.com/2006/3/amazon-web-services-launches" target="_blank" rel="noopener noreferrer">AWS launch announcement</a> <a href="https://en.wikipedia.org/wiki/Amazon_S3" target="_blank" rel="noopener noreferrer">Wikipedia: Amazon S3</a> <a href="https://aws.amazon.com/s3/" target="_blank" rel="noopener noreferrer">Amazon S3 product page</a> <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html" target="_blank" rel="noopener noreferrer">AWS Docs: What is Amazon S3?</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="S3 shifted the architectural trade-off from self-managed infrastructure to cloud-managed storage services.">Ch. 1: Data Systems Trade-offs</span><span class="ddia-chip" data-why="S3 serves as the distributed filesystem substrate underlying modern batch processing pipelines.">Ch. 11: Batch Processing</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Distributed storage" data-search="2006 bigtable paper / distributed storage system distributed storage fay chang, jeffrey dean, sanjay ghemawat, wilson hsieh, deborah wallach, mike burrows, tushar chandra, andrew fikes, robert gruber, google google needed structured storage for petabyte-scale data across thousands of machines. bigtable implemented a sparse, distributed, persistent, sorted multidimensional map. influenced hbase, cassandra, and wide-column database design.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2006">2006</time>
                    <h3>Bigtable</h3>
                </div>
                <span class="badge">Distributed storage</span>
            </div>
            <div class="meta"><span>paper / distributed storage system</span><span>Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson Hsieh, Deborah Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert Gruber, Google</span></div>
            <div class="problem"><strong>Problem solved:</strong> Google needed structured storage for petabyte-scale data across thousands of machines.</div>
            <div class="solution"><strong>How it solved it:</strong> Bigtable implemented a sparse, distributed, persistent, sorted multidimensional map.</div>
            <div class="impact"><strong>Why it mattered:</strong> Influenced HBase, Cassandra, and wide-column database design.</div>
            <div class="refs"><strong>References:</strong> <a href="https://research.google/pubs/bigtable-a-distributed-storage-system-for-structured-data/" target="_blank" rel="noopener noreferrer">Google Research: Bigtable</a> <a href="https://en.wikipedia.org/wiki/Bigtable" target="_blank" rel="noopener noreferrer">Wikipedia: Bigtable</a> <a href="https://dl.acm.org/doi/10.1145/1365815.1365816" target="_blank" rel="noopener noreferrer">ACM TOCS: Bigtable</a> <a href="https://cloud.google.com/bigtable" target="_blank" rel="noopener noreferrer">Google Cloud Bigtable</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Bigtable’s SSTable and LSM-tree storage engine are key examples of log-structured retrieval systems.">Ch. 4: Storage & Retrieval</span><span class="ddia-chip" data-why="Bigtable partitions data by sorted row-key ranges across tablet servers for horizontal scalability.">Ch. 7: Sharding</span></div>
        </article>

        <article class="milestone" data-era="2000s" data-category="Big data processing" data-search="2006 onward hadoop software / open-source ecosystem big data processing doug cutting, mike cafarella, yahoo, apache community google-style distributed storage and batch processing were not available to most organizations. hadoop provided open-source hdfs and mapreduce on commodity clusters. made big-data processing accessible across industry and academia.">
            <div class="pin" aria-hidden="true"></div>
            <div class="card-head">
                <div>
                    <time class="year" datetime="2006">2006 onward</time>
                    <h3>Hadoop</h3>
                </div>
                <span class="badge">Big data processing</span>
            </div>
            <div class="meta"><span>software / open-source ecosystem</span><span>Doug Cutting, Mike Cafarella, Yahoo, Apache community</span></div>
            <div class="problem"><strong>Problem solved:</strong> Google-style distributed storage and batch processing were not available to most organizations.</div>
            <div class="solution"><strong>How it solved it:</strong> Hadoop provided open-source HDFS and MapReduce on commodity clusters.</div>
            <div class="impact"><strong>Why it mattered:</strong> Made big-data processing accessible across industry and academia.</div>
            <div class="refs"><strong>References:</strong> <a href="https://cloud.google.com/learn/what-is-hadoop" target="_blank" rel="noopener noreferrer">Google Cloud: what is Hadoop</a> <a href="https://en.wikipedia.org/wiki/Apache_Hadoop" target="_blank" rel="noopener noreferrer">Wikipedia: Apache Hadoop</a> <a href="https://hadoop.apache.org/" target="_blank" rel="noopener noreferrer">Apache Hadoop official site</a> <a href="https://www.dataversity.net/a-brief-history-of-the-hadoop-ecosystem/" target="_blank" rel="noopener noreferrer">Dataversity: History of the Hadoop Ecosystem</a></div>
            <div class="ddia"><strong>DDIA:</strong> <span class="ddia-chip" data-why="Hadoop’s HDFS and MapReduce ecosystem are the primary batch processing case study in this chapter.">Ch. 11: Batch Processing</span></div>
        </article>