Centralized data: what changed when we put our business in one place

A database, in plain words, is one place your business owns where its information is kept: your client list, your quotes, your invoices, your appointments. "Centralized" means there is one such place, not one per app.

Most of what you will read about centralized data is definitions and benefit posts, and few show a small business's move. Domo's guide to the benefits of data integration opens with a line we agree with: "Scattered information costs more than most companies realize." What those guides rarely show is what a small business actually changed, and what it cost. This page shows ours: one business's dated record of the move, the gains and the costs.

This page is by the clevrstart team. We build these systems, and we moved our own business into one place we own. For the whole method, read our guide on How to centralize your business data.

Our move: from separate databases to one, in dated steps

Before 2026-08-06, each of our apps had its own database and its own login list. Our websites, our content engine and our booking app each kept their own information, and each kept its own list of users.

On 2026-08-06 we moved them into one database we own, on Postgres, in sections: business records and site content, the content engine, and bookings. The PostgreSQL documentation on schemas explains how one database holds separate sections like these. The agents service joined later. On 2026-08-18 we merged the login lists into one.

Counted on 2026-10-14, the one place holds 483 tables for business records and site content, 47 for the content engine, 11 for the agents service and 6 for bookings. These are tables, the lists that hold one kind of information each, not the number of items in them.

We started the way we tell readers to start: with a list of what each app kept. Our page on how to organize business data shows that list step by step.

What changed: the gains, with dates and counts

Here is what changed for us, from our own records. We did not measure time or money saved, so none is claimed.

While two login lists existed, an item could point to the copy of a user in the second list, and the save failed without telling anyone. With one login list, each item points to the one copy of the user.

Alation's guide to data governance models defines data governance as how data "is gathered and used within an organization." With everything in one place, that question has one answer for us: one login list, one door for agents, an API key checked on every request.

Before you move, check that the place you choose can do the same. Our checklist for a centralized database for small business lists seven checks to run on any option. The three that decide the most: each thing is kept once and linked, you can export everything yourself, and the accounts are in your name.

We rehearsed every step on a full copy first, never on the live database. We moved one app at a time: copy its information, point the app at the new place, start it, test it. We kept the old databases until the new one had run clean for a week. We moved the logins last, and everyone signed in again once.

What we did not measure: hours spent, hours saved, money saved. We report what changed, not a return.

Our page on hosting and your data sets out the rule we keep for client projects: the accounts are opened in your name before the first line ships, and where your data lives is written down for your project, not assumed.

Is it right for you: a fair test for a 1 to 20 person business

You will probably find that centralized data fits your business. First San Francisco Partners' guide to choosing a governance model notes that the centralized model "works best for organizations that need strong control, consistency, and regulatory compliance," and names small or medium organizations with fewer departments as a good fit. The same guide warns that departments "may experience delays in accessing data" when every request goes through one central team.

A fair test: if you keep the same client in two or more apps, or you match bookings and invoices by hand, centralizing will change your week. If all your information already sits in one tool that passes the export test on our page about what a business operating system is, you may already be there.

When one place is the wrong fit

One place is not right for everything. One product we sell to other businesses keeps its own database on purpose, so its users and ours never mix. Two different sets of customers, with different owners, belong in different places.

The rule we use: information that belongs to the same business, and is changed by the same people, goes in one place. Information that belongs to someone else stays in their place.

Your next step: check your own records before you move anything

Before you move anything, list what you keep and where. Our free business data inventory lists what you keep and shows what you keep twice. Then run the seven checks on the place you plan to use, rehearse the move on a copy, and keep the old app for a week.

If you are thinking of a build rather than a product, our Software Development Cost Calculator shows a first estimate of what a first version takes. Our founder's column, Why I put my whole business in one database, explains the longer story of our move.

If you want help, the first step is a call: thirty minutes. Scope, feasibility, complexity, then a number. The call and the number are free; you owe nothing until you accept one.