stuart/databuild
1
1
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

why not sql backend

Browse source
This commit is contained in:
Stuart Axelbrooke 2025-11-24 21:59:16 +08:00
parent 61c13cdcc0
commit dfc1d19237
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/narrative/why-not-sql-backend.md
View file

@ -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.