A startup's checkout must insert an order, its line items and a payment row as one unit, and the database itself must reject any payment that references an order that does not exist. Which database type best fits these requirements?

Relational databases organize data into tables with declared keys, and they enforce referential integrity through foreign key constraints: an INSERT into payments that names a nonexistent order_id is rejected by the engine, not by application code. They also wrap multiple statements in a single ACID transaction, so the order, its line items and the payment are committed together or not at all. Those two properties map directly to the requirements. A key-value store treats each value as opaque and has no concept of a constraint linking one key to another, so orphaned payments would be possible unless every client enforced the rule itself. A column-oriented store is optimized for analytical scans that read a few columns across many rows; compression and columnar reads do nothing to enforce relationships or make a multi-row write atomic. A time-series database is built for timestamped appends and range aggregation, which is the wrong shape for transactional order data with parent-child links. Exam caveat: some NoSQL products now offer multi-document transactions, but the objective contrasts relational and non-relational by their defining traits, and declared referential integrity is a relational trait. Operational check: create the orders and payments tables with a FOREIGN KEY on payments.order_id, then attempt an insert with a fake order_id and confirm the engine rejects it.