Y2K, 640K and lessons for database creation

Get both examples right first, because they are routinely misdescribed. The Y2K problem was a deliberate design decision, not a mistake: storing years as two digits saved expensive storage when storage was the binding constraint, and the assumption was that the software would be replaced before it mattered. It was not, and the reason nothing much happened in January 2000 is that an enormous remediation effort had already taken place — which makes Y2K a case of a limit correctly identified and expensively fixed rather than a scare that proved groundless. The 640K quotation is a different animal: it is misattributed, Gates denies saying it, and its currency comes from the fact that the memory limit was real even if the confident dismissal was invented. So one example is a limit that arrived, and the other is a limit that was designed around and then embarrassed by hardware.

The lesson for database creation follows from reconciling them, and it is not simply 'plan for growth', which would be too cheap. Both cases are about an assumption baked into a structure and then forgotten. In database terms that means: choose data types by what the domain permits rather than by what current data contains, since a field sized to today's values is a future migration; document the assumptions in the schema itself rather than in somebody's memory, because the Y2K cost was largely in finding the affected code; expect the system to outlive its intended lifespan, because successful systems are exactly the ones that do; and prefer designs where a limit can be raised without rewriting dependent code. Add the counterweight honestly — over-provisioning has real costs too, and a schema designed for every conceivable future is unusable now. The judgement is about which assumptions are cheap to relax later and which are not, and that is the answer worth writing.