Two writers on one schema cannot be released independently

Two deployables reading and writing the same tables cannot change their schema independently and fail together, which removes every property a separate service was supposed to provide.

orders-service  ──┐
                  ├──>  shop.orders     ← both write. one schema.
billing-service ──┘

the question that settles it:
  can one of them add a NOT NULL column without coordinating
  a release with the other?

if not, they are one service with two deployment artefacts —
which is strictly worse than one service.

The shape arrives by accident: a second application needed data, the database was there, and reading from it was faster than building an endpoint. Undoing it means one service owning the tables and the other going through an API or a replicated read model, which is months. Naming it out loud is most of the work, because it is usually defended as pragmatism when the actual cost — coordinated releases forever — has never been stated.