From dfc1d19237be0328a65f1b5891e215fb147f5149 Mon Sep 17 00:00:00 2001 From: Stuart Axelbrooke Date: Mon, 24 Nov 2025 21:59:16 +0800 Subject: [PATCH] why not sql backend --- docs/narrative/why-not-sql-backend.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/narrative/why-not-sql-backend.md b/docs/narrative/why-not-sql-backend.md index a44ede6..01d40bc 100644 --- a/docs/narrative/why-not-sql-backend.md +++ b/docs/narrative/why-not-sql-backend.md @@ -1,4 +1,4 @@ -If you look at the collection of state machines, objects, and state transitions that make up databuild, its tempting to ask, should this be implemented by a SQL database instead with constraint checks and foreign keys? +If you look at the collection of state machines, objects, and state transitions that make up databuild, it's tempting to ask, should this be implemented by a SQL database instead with constraint checks and foreign keys? -TODO +Answer: it is tempting! But at its core, databuild models the coordinated state machines of Wants, Partitions, and Job Runs. Compile-time correctness checks of the integrity of the system that are possible via rust with type-state style object state machines and typed object IDs do more to mitigate system integrity risks than foreign key checks mitigate. And after all, we panic on reference errors already, so should detect related issues systematically.