Data models
A data model is the shape in which a database keeps data, such as tables, documents or keys. A document store reads one product with all its attributes in about 0.3 ms. A model that matches the main queries needs fewer joins and less work for each read.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Products in a relational table | Products in a document store |
|---|---|---|---|
| p99 latency | under 150 ms | 10.1 s Fail | 24 ms Pass |
| Monthly cost | 8 USD/mo | 8 USD/mo | |
| Error rate | 99.974% | 0% |
Key numbers
| Number | Value |
|---|---|
| Document store read, median | 0.3 ms |
| Relational database read (Postgres), median | 0.5 ms |
| Operations per second, one document store | 30,000 ops/s |
| Queries per second, one relational database | 15,000 ops/s |
Tables · a read touches 3 places in 0.5 ms · a shared change writes 1 place
How it works
Each data model makes some queries easy and others hard. A relational database keeps rows in tables with a fixed set of columns. It is good at joins, constraints and transactions across tables. A document store keeps each record as one nested document, so items with different fields fit without empty columns. A key-value store finds one value by its key very fast, but it cannot search inside the value. A graph database follows links between items, and a time series database keeps values in time order.
Start from the queries, not from the data. List the reads that the system does most often and the filters that they use. Choose the model where those reads touch one place on disk. If a product page needs one product with all its attributes, a document fits. If a report joins orders, customers and payments, tables fit.
A model is not free. Documents copy data that tables would share, so one change can need many writes. Tables with many optional attributes need many joins or many empty columns. In each model, a query on a field still needs an index on that field.
In the levels you match the data model to the queries that the system must serve.