Where the schema goes when there isn't one
A document store has no table to lock and no ALTER to write. What it has instead is two shapes of the same thing in the collection at once, and nothing that will tell you so.
11 minutes · versioned documents · readers per version · batch job · dual writes
Everything the relational tracks warned you about is gone
There is no ALTER TABLE, so there is no ACCESS EXCLUSIVE, no rewrite, no queue and no head-of-line blocking. Adding a field to a document store is not a migration at all: you write a document with the field, and it has the field.
That is a real advantage and it is worth being precise about what it buys. It removes the whole of the locks track and the whole of the rewrite track. It removes nothing from the expand-and-contract track, because that one was never about locks.
What is left
The shop's orders are in a collection. Forty-one million of them have a note field. The new version of the application writes memo instead, and a job is converting the old documents across.
Predict
While that job runs, and half the collection has been converted, what fraction of reads break?
Expand and contract, without a schema to expand
The answer is the same one the relational track gives, and for the same reason. Convert documents to a shape that has both fields. A document with note and memo breaks neither reader, so every document the job touches stops breaking anybody and the number actually falls.
Then, once the old deploy is gone, a second pass drops note. Two passes instead of one, and neither of them is an outage.
Set the plan to a two-field shape below and run it beside the one-field version. The run length is nearly identical; the broken-read count is not.
The database was never the thing that made a rename hard. Two versions of the code reading the same data at the same time is, and no storage engine has ever solved that for anybody.
The job that never finishes
There is one failure mode with no relational equivalent. If the application is still writing the old shape while the job converts it, the job is chasing its own tail: it catches up, the collection reaches one shape for an instant, and the next write undoes it.
This does not look like a failure. The job reports progress, the counts move, and the collection never settles. Turn off New writes take the new shape below and watch the regression count climb.
MongoDBA schema validator can refuse documents that do not match a shape, which turns the silent version of this into a loud one. It is opt-in, it is per-collection, and it is the closest thing to a NOT NULL constraint on this side of the fence.
The collection
The same one every claim above was made about. Nothing here is graded — run whatever you like.
The collection
- v1 (note)41M documents_id, customer_id, total, status, notebreaks v2
- v2 (memo)0 documents_id, customer_id, total, status, memobreaks v1
41M documents · 120 reads and 40 writes a second, and no lock anywhere.
The plan
There is no `ALTER` here and no lock to take. Everything above is a decision in application code.
Nothing has run yet. How long it takes, and how many reads break while it does, is the question.
Answer the 1 prediction above first.
All tracks