A team wants to move a workload from PostgreSQL to a document store because "the schema keeps changing". What do you ask?

The questions

1. What is actually changing — the shape, or the schema management process?

"The schema keeps changing" usually means migrations are painful, not that the data is genuinely polymorphic. If the pain is coordinating a migration across deploys, or locking a large table, those are solvable — expand-and-contract, online DDL, CREATE INDEX CONCURRENTLY — and moving store does not address them.

2. Does the schema disappear, or just stop being enforced?

It does not disappear. It moves into application code, where nothing checks it, several services may disagree about it, and a field's meaning drifts between versions with no error. Teams that adopt a document store for schema flexibility usually reintroduce validation within a year, in application code, less reliably.

3. What are the access patterns?

The genuine case for a document store is that an aggregate is the unit of access — load the whole order with its lines and history in one read. If queries cut across documents, filter on many different fields, or aggregate, you are buying the wrong model.

4. Have you tried jsonb?

Postgres supports indexed JSON columns with path queries and partial indexes. A hybrid — relational for the stable core, JSON for the genuinely variable part — gets the flexibility without a second datastore, second operational surface, second backup strategy and second set of expertise.

5. What do you lose?

Joins, foreign keys, and — depending on the store — the maturity of the query planner and tooling.

What I would probably recommend

Stay, and use jsonb for the variable portion. It is the option that addresses the stated problem with the least cost, and it is reversible: promoting a JSON field to a real column later is a migration, whereas migrating stores is a project.

Move only if the aggregate access pattern is genuinely dominant, the variability is real rather than a symptom of an unfinished domain model, and the team has weighed running two stores.

What a strong answer adds

Naming the failure this usually precedes: schemaless storage plus relational query patterns. The team avoids designing a schema, then needs to query across documents, then builds application-side joins — ending up with a system that is both slower and less capable than the one it replaced.