Subscribe for more posts like this →

A shared database is a hidden broadcast channel.

Two services that share a database are one service pretending to be two.

Every schema migration is a message sent to every connected service — simultaneously, without versioning, without a consumers list, without warning.

You add a NOT NULL column to tighten data integrity. Three services you didn’t know wrote to that table start failing in production before anyone notices the migration ran.

You drop a column after grepping the codebase and finding zero references. A service built by another team was reading it directly from the DB, bypassing your API. It silently starts returning nulls.

You rename a field for clarity. The old name was a string in a config file nobody thought to grep. Two services break. The incident ticket says “unknown cause.”

Nobody made a mistake. The schema changed and the broadcast went out. Not everyone was listening.


In a service-to-service API, a breaking change is visible. You version the endpoint. The consumer negotiates. There’s time.

In a shared database, there’s no versioning. No negotiation. The schema changes and every observer finds out at the same moment — when their query breaks.

Your deployment pipeline says independent. Your schema says otherwise.


So when someone says “let’s just share the DB for now” — how many consumers are on that broadcast channel?

And do any of them know they’re subscribed?


Byte-size distributed systems, one insight at a time.

Read more