Orders live in PostgreSQL. Support tickets live behind a REST API. Inventory lives in SQL Server, which the warehouse team runs and nobody else is eager to touch. The same customer shows up in all three, late, and under slightly different ids. A director asks for one picture: which open tickets belong to orders that have not shipped?
The standing proposal is a central database. It was started last year. The first three tables landed. Then the ticket API changed its pagination, the person who owned the pipeline moved teams, and the warehouse sat at "we'll backfill the rest next quarter." Next quarter became the quarter after. The question on the table cannot wait for the backfill.
Scattered departmental data is not a lack of databases. It is the same facts, arriving late, in systems that belong to different teams. The central store is the usual answer, and building it is the project that does not stay finished, because every source keeps moving and the team that would maintain the copy has a day job.
What the central store is for, and what this question is for
A warehouse is a fair answer when many people need the same history, in the same shape, every day, and someone is paid to keep the pipes. Conformed customers, a stable notion of "shipped," a place an auditor can rerun last March: those are warehouse jobs. They are not free, and they are not a prerequisite for one join you need this week.
The failure mode is using the warehouse as a gate. No cross-system question is allowed until the platform is done, and the platform is never done, so the question is answered with three exports and a meeting. The practical question is narrower: read across the systems you already have, on the ids they already share, and write down how fresh each one is. That is smaller than a customer-360 program.
Why the usual tools assume the data has already been gathered
A SQL client sees one engine. The orders client can list unshipped orders. It cannot see the ticket API. The person copies ids into the API console, or into a sheet, and does the join with their eyes. That works for ten tickets. It does not work for the queue.
A BI tool wants the data loaded, or at least modeled, before it will draw the picture. If the load is the stalled project, the BI tool is waiting on the same unfinished work. It is not a way around it.
Excel will take three exports and a lookup. You are then maintaining a shadow warehouse in a workbook. The file feels like progress because it has all the columns. It expires tonight, and the next person will make their own.
A text-to-SQL chat on the orders database is fluent about orders and silent about tickets. Paste a sample of the API into the prompt and you can get a plausible story about those few rows. You cannot get the queue. The chat's world is the connection it was given, plus whatever text you added. Departmental reality is three connections and a freshness lag.
Each tool is built for data that has been put in one place. The pain is that putting it in one place is the project that stalled. A tool that can only start after that project finishes cannot answer the director this week.
Read across the systems for the question you have
Name the fact, then name the system that owns it. Order status, including shipped or not: the orders database. Ticket state, including open or not: the API. On-hand quantity: inventory. Write that down in three lines. The central database, if you build it later, copies those systems. It does not become the authority by existing. When the copy and the source disagree, the source wins, and the copy is stale. Say so now, or the copy will quietly become the number people trust because it was easier to query.
Join on a stable id. If the ticket payload has order_id, that is the key, and the question is answerable where the data sits. If the ticket has only a customer name, you do not have a join. You have the reconciliation problem, and a warehouse will not solve it until someone builds the alias table. Build the alias table first. It is smaller than a platform.
Accept lateness as a property of the source. If the shop batches orders overnight, a query at 16:00 will not invent the missing rows. Put the freshness next to the number: "tickets as of the last API response, orders as of now, inventory as of the 06:00 snapshot." A late number with a clock is usable. A number that pretends to be live is how the next argument starts.
Move data when you have a repeated consumer and a person who will keep the pipe. One question, asked once, does not justify a new store. The same question every morning, asked by six people, might. The test is whether someone owns the failure when the API changes. If nobody does, leave the data where it is and pay the cost of a cross-source query. That cost is visible. A pipeline with no owner fails in the dark and still looks like a system of record.
Do not widen the project to every department because one director asked one question. Orders, tickets, and inventory answer this question. Finance can wait until finance has a question. A central database that tries to absorb every system on day one is the one that stalls at three tables.
Where DataTug fits
DataTug helps by leaving each system where it is and opening it in one project, then joining or asking across those sources in the web app, the CLI and terminal UI, or AI chat. For this story that is PostgreSQL, a REST API, and SQL Server, which are on the list the site marks as working today: SQLite, PostgreSQL, MySQL, Oracle, SQL Server, BigQuery, inGitDB, and REST APIs. An agent can use the same project through the Claude Code skills plugin or the MCP server.
That is a way to answer "which open tickets belong to orders that have not shipped?" without finishing the warehouse. It is not a warehouse. It does not keep history the sources themselves do not keep, and it does not conform a customer record you have not defined. The sentence about which system owns which fact is still yours. So is the alias table, if the ids do not match.
Personal and public projects are free. If you want to see two sources in one project before you connect the departmental ones, start with the demo, which needs no account, or open datatug.app and add the sources you are allowed to read. Leave the central-database ticket open if you still want it. Do not make this week's answer wait on it.