“Schemaless” sounds fast until different teams start storing the same business concept in slightly different shapes. At that point the schema did not disappear. It just moved into application code, migration scripts, and production support incidents.
That is why many teams eventually land on Postgres with JSONB as a compromise: relational guarantees for core fields, flexible document storage for the parts that actually change often.
Why JSONB Works as a Middle Ground
The useful pattern is not "put everything into a JSON column." It is to separate stable business fields from evolving metadata:
CREATE TABLE users (
id UUID PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
plan TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
preferences JSONB NOT NULL DEFAULT '{}'::jsonb
);
CREATE INDEX users_preferences_gin_idx
ON users
USING GIN (preferences);
That gives you:
- normal relational constraints for important fields
- JSON querying for variable preferences or feature flags
- one operational platform instead of split storage models
Where Teams Usually Regret Pure Document Storage
Document databases can still be a good fit, but the pain often shows up when the system grows:
- cross-document consistency becomes harder
- reporting wants relational queries
- duplicate field shapes accumulate
- migrations become ad hoc data repair work
If the application has money flows, billing state, identities, or high-value joins, Postgres usually ages better.
The Honest Trade-Off
JSONB is powerful, but it is easy to misuse. If every meaningful field ends up buried inside JSON, you lose a big part of why relational storage helps in the first place. Use it for selective flexibility, not as an excuse to avoid schema design.
MongoDB is not "wrong." The mistake is assuming schemaless storage is cheaper forever. It is often cheaper only at the very beginning.
Further Reading