Symphony Apps Development logo — teal interlocking S monogram beside the studio wordmark
All writing

What breaks when two teams share a database

A shared database looks like an integration shortcut. It's usually a coupling nobody agreed to.

Category
Engineering
Reading time
6 min
Published
20 Apr 2026
Topics
Engineering, Process

Two teams on a client's side wanted their systems to share data quickly, and the fastest route on paper was letting one team's service read directly from the other's database. It worked for two months, and then a routine column rename on one side took down a report nobody remembered depended on it.

The appeal is real

No API to design, no versioning, no waiting on the other team's roadmap. For a short-lived project this can be the right trade. The problem is that "short-lived" integrations tend to outlive the assumption that made them cheap.

What actually coupled

Not just the schema — the query patterns. The reporting service had written a query that assumed a particular index existed for performance reasons, an index the owning team had no idea anyone outside their service depended on. Removing it during an unrelated optimisation slowed the report from seconds to minutes with no warning to either side.

The fix we recommended

  • Put a contract between the two systems, even a thin one — a view, or a small read API — so the owning team can change their internal schema freely as long as the contract holds.
  • Make the dependency visible. The owning team genuinely didn't know the report existed; a shared database has no mechanism for that visibility that an API endpoint's access logs would have provided for free.
  • Decide who owns a breaking change. With direct database access, a breaking change is whoever touched the schema last, which is not the same as whoever should be accountable for it.
Sharing a database isn't an integration. It's two teams agreeing, usually without saying so, to move at the same speed forever.

What it cost to unwind

Around three weeks to build a proper read API and migrate the report to it, which is not nothing, but it was three weeks chosen deliberately rather than three weeks spent firefighting the next unannounced schema change.

When we'd still allow it

Within a single team, or for genuinely temporary tooling with an agreed deletion date. Across team boundaries that will persist, we now recommend the API from day one, even a minimal one, because the alternative is a coupling that's invisible until it fails.

Tell us what you’re trying to ship

A first call is thirty minutes and costs nothing. Bring the problem, not a spec — working out what to build is the part we are good at.

Or email office@symphonyapps.ro. We reply within one business day, in English or Romanian.