When two databases hold the same customer, you have two truths.

Most founder-led distributors who sell online end up with two databases without ever deciding to. The storefront arrives first, usually WooCommerce on MySQL, because it is the fast way to get a catalogue and a cart online. The operational system arrives later, a custom ERP or a back-office tool on PostgreSQL, because the storefront was never going to run the business. Each is a sensible choice on its own. Together they create a problem that does not announce itself: the same customer, and the same product, now live in two places.

This essay is about the cost of that arrangement, why it stays invisible for years, and the point at which collapsing the two databases into one becomes the cheaper option rather than the ambitious one.

The same record in two places is not one record

A customer who registers on the storefront exists in the storefront's database. The same customer, once they have ordered, also exists in the ERP. These are two rows in two systems. They agree only because something keeps them in agreement. The same is true of every product and, most expensively, of every price.

The something is a sync: a piece of integration code that reads one system and writes the other. While it runs correctly, the two databases behave as if they were one, and everyone forgets there are two. That forgetting is the danger. The architecture is fine right up until the sync is not, and the gap between those two states is where the cost lives.

The sync is the part that breaks

A sync built on top of WooCommerce inherits WooCommerce's surface, and that surface moves. Plugins update. A field shifts between versions. An API key rotates. A change that looks cosmetic from the storefront side breaks the contract the sync depends on, and the sync stops.

It rarely stops loudly. There is no alarm when a price stops propagating. The first sign is downstream and human: a customer is quoted one price on the store and invoiced another, or an order arrives in the ERP missing a field the team expected. By the time someone notices, the two databases have been disagreeing for a while, and the work is not just fixing the sync but finding and correcting everything that drifted while it was down.

This is the debt. It is not a one-time integration cost. It is a standing liability that the firm services with attention, paid in the small emergencies that come from two systems silently falling out of step. The firm does not own the surface the sync sits on, so it cannot prevent the breakage, only react to it.

Why it stays invisible

The debt is invisible because it is paid in scattered moments rather than on an invoice. Nobody budgets for "reconciling the customer table." The cost shows up as a confusing afternoon, a customer complaint, a manual correction, and then it disappears until the next time. Each instance is small enough to absorb and forget, which is exactly why the total is never counted.

It is also invisible because the architecture is so common that it reads as normal. Everyone in the category runs a storefront in front of a back office. The two-database shape feels like the way things are done, not like a decision that could be revisited.

When one database becomes the cheaper answer

The two-database architecture is the right starting point more often than not. It gets a firm online quickly and lets each system do what it is good at. The question is not whether it was right to begin with. The question is when the standing cost of the sync exceeds the cost of removing it.

That point arrives when the volume of shared data is large enough, and the business depends on it enough, that a silent drift is no longer a nuisance but a real operational risk. At that scale, the answer is to stop syncing two databases and start using one. A storefront does not need its own database. It can read from and write to the same database the ERP runs on, so that a customer is written once, an order lands in the operational backend directly, and a price is correct because there is only one copy of it.

When the second database goes away, so does the sync, and so does the entire class of failure that came with it. There is nothing to fall out of step. We did exactly this for AK Suppliers & Distributors: retired WooCommerce and its MySQL database, rebuilt the storefront as a custom Next.js application on the ERP's own PostgreSQL, and removed the sync as a component rather than maintaining it.

The decision, framed honestly

Collapsing two databases into one is not free. It means rebuilding the storefront rather than buying it. The trade is that you stop paying the sync debt forever in exchange for a one-time build. For a firm still finding its footing online, that trade does not pay. For a firm whose order volume and data dependence have grown past the point where a silent sync failure is tolerable, it pays clearly, because the build replaces a maintenance surface instead of adding one.

The signal to watch for is simple. When your team has started to distrust your own prices, or routinely checks whether two systems agree before acting, you no longer have one source of truth. You have two truths and a hope that they match. That is the moment to make them one.