Four services want four different databases: Postgres, MongoDB, Cassandra and Neo4j. What do you say?

The response: make each team justify it against a default

Polyglot persistence is legitimate and routinely over-applied. The question for each is not "is this database good?" but "what property does this workload need that our default cannot provide?"

Set a default — Postgres, most likely — and require a stated, specific reason to depart.

MongoDB: does the workload genuinely centre on aggregates with variable shape, and has jsonb been tried? Postgres with indexed JSON serves a large share of document workloads, and keeping one store is worth a lot.

Cassandra: what is the write volume and the scale? Cassandra earns its cost at very high write throughput with predictable single-partition access and multi-region replication. Below that, it is a harder operational commitment than a well-tuned Postgres, and its constraints — no joins, no ad-hoc queries, design-per-query — are severe.

Neo4j: how much of the workload is multi-hop traversal? If it is a minority, the graph store will sit alongside a primary store rather than replacing it, and you have gained a system rather than solved a problem. Postgres recursive CTEs handle shallow traversal adequately.

The cost nobody puts in the proposal

Four stores means four sets of: backup and verified restore, patching and version upgrades, monitoring and alerting, capacity planning, performance expertise, security review, disaster recovery testing, and on-call knowledge. It multiplies the platform team's surface, and it fragments the expertise that would otherwise deepen.

It also fragments querying: cross-store questions now require a warehouse or an API composition that would have been a join.

Where I would probably land

Postgres as default for at least two of them, with a genuine case likely for one specialised store. And if a departure is approved, it should come with an owner, a documented operational runbook, and inclusion in the platform's standard tooling — not a database that one team runs and nobody else can support.

What a strong answer adds

Distinguishing polyglot persistence from database per service. The second is about ownership and is nearly always right in a service architecture; the first is about technology variety and should be exceptional. Four services each owning their own Postgres database is polyglot in neither sense and is usually the right answer.