Portfolio · Written for this search · database
Database
Systems desk
A database is an agreed place to keep records so that they can be found again. The Systems desk treats it as a promise about the future: what was written must still be readable, and still mean the same thing.
- Source of records
- Schema
- Write path
- Stored records
- Query
- Reader
What the concept is
A database holds records under rules. The rules say what a record must contain, how records relate, and who may change them. Without the rules you have a pile of files.
The Systems desk separates three things. The records are the content. The schema is the shape. The query is the question. Most failures come from letting one drift away from the other two.
How it is arranged
The diagram shows one direction of travel. A source produces records. The schema checks them against an agreed shape. The write path commits them. The store keeps them. A query reads them back for a reader who may not be the original author.
The schema sits before the write path on purpose. A record that fails the shape should be refused at the door. Repairing it after storage is slower and harder to audit.
Where it meets the portfolio
Computational work leaves records behind. Sampled outcomes from measurement and sampling are only useful later if each batch is stored with the circuit and settings that produced it. Otherwise the counts cannot be interpreted.
The same holds where classical and quantum steps alternate, as in hybrid execution. A shared store lets each step pick up the last step's output. The desk makes no claim here about any particular product. The wider catalogue is at the portfolio.
Finding from this desk
The Systems desk's position is that a database is defined less by its storage than by its schema and its queries. Together they fix what a record means and what can be asked of it later. No benchmark was run for this note, and it claims no performance figures.