--- title: "You Didn't Choose Your Split Architecture. You Accumulated It." published: 2026-11-10T10:00:26.000-05:00 updated: 2026-11-10T10:00:26.000-05:00 excerpt: "A second database rarely arrives as a decision. It arrives as a series of reasonable fixes, and the bill arrives anyway." tags: None authors: Matty Stratton --- > **TimescaleDB is now Tiger Data.** Ask a team when they decided to run a second database and nobody remembers the meeting, because there wasn't one. A slow report, a cautious feature launch or an org boundary adds a system, and each step looks reasonable on its own. The cost is structural: a second copy isn't the source of truth and isn't current when you query it, however good the pipeline is. Sometimes a separate system is the right call. It should still be a decision. ## Nobody remembers the meeting Ask a team when they decided to run a second database, and you'll get a confident answer about evaluating options and picking the right tool for the job. Then ask who was in the meeting. The room gets quiet, because the meeting never happened. A split architecture is a system where your application's data lives in more than one database: usually Postgres for transactions, plus a second store holding a copy for analytics or for one particular feature. For many teams, it doesn't start as a plan. It shows up one reasonable fix at a time. The "we evaluated and chose" story gets written afterward, the way you explain a scar at a party. (Oh, that? Totally intentional.) This post is about how a split forms without anyone choosing it, what the second copy costs no matter how good your tooling is, and when adding a system is the right call. ## How a split happens Here are three ways it often goes. These are composites, stitched together from patterns, so none of them is any one company. You'll probably recognize at least one. ### The reporting detour Someone builds a report. It's a good report, so people run it constantly, and eventually production flinches every time finance opens the dashboard. So you point the report at a [read replica](https://www.tigerdata.com/blog/read-replicas-dont-solve-write-bottlenecks). Problem solved. Then the report wants data shaped in a way the replica makes painful, so someone starts exporting it nightly to a store that's friendlier for analytics. A second report moves over, because the first one already lives there. The new store picks up a dashboard tool, a service account and somebody whose job now includes keeping it alive. Congratulations, you run an analytics platform. Nobody filed the ticket for it. ### The feature with its own database A new activity feed needs to store events. The team isn't sure about the data model yet, and nobody wants an experiment anywhere near the production schema, so it ships on its own small database. Just for now. The feature works. People use it. "Just for now" quietly becomes "how it works." From then on, every new piece of data needs a home, and the new database is always one of the options. Each time it wins, the second database gets a little harder to retire. ### The inherited stack Sometimes the second database arrives with the org chart. An acquisition is the classic version. The new team shows up with its own product, its own database and its own way of doing things, and nobody is rewriting either side on day one. So an integration job syncs the records the business needs between them, a few times an hour, so support can see every customer in one view. It never stays one view. Billing wants one invoice, so billing starts reading from the sync. Then sign-up checks it to stop duplicate accounts, and now a customer-facing flow depends on a job nobody designed to carry that weight. The people relying on it don't care which side of the deal the data came from. They want the right customer, now. Nobody decides to keep both. Nobody decides to merge them, either. The connection just stays. Look at any single step and you'd probably make the same call. A replica for a heavy report is sensible. Fencing off an experiment is prudent. Keeping two companies' systems talking is the job. That's what makes this so sneaky. Every step was reasonable. You don't choose a split architecture. You accumulate one. ## The tell: "it works today" So how do you know you're already there? Listen to how people talk about it. In conversations with teams, an existing split is more often defended with "it works today" than argued on its merits. You won't hear anyone say "keeping two copies of our order data is the right design, and here's why." They argue for leaving it alone. That phrase is the tell. A decision made on purpose gets defended with the reasons someone made it. A split that accumulated has no reasons to point to, so the best anyone can say is that it hasn't fallen over yet. For now, just notice when you hear it. ## What a second copy costs Assume the best version of your setup: the pipeline took no effort to build, never breaks and never pages anyone. The copy still costs you, because a split nobody decided on is a copy nobody specified. Nobody decided which copy is the truth. A second copy that is updated asynchronously is not the source of truth, and nothing guarantees it's current at the moment you query it. The [transactional guarantees](https://www.tigerdata.com/learn/understanding-oltp) you lean on in your primary database don't span the two systems: a query on the copy can't see what the primary just committed. That's survivable when everyone knows which copy wins. In an accumulated split, nobody ever said, so each team trusts whichever copy it happens to query. Nobody decided how stale is acceptable. A lag you chose has a number attached and someone watching it. A lag you accumulated is whatever it happens to be today. (Do you know yours right now? For every table?) Nobody owns keeping it correct. Someone keeps the copy running. Keeping it right is a different job, and in an accumulated split it belongs to whoever notices first. Quarter end is where the bill shows up. Take an illustrative case. Finance pulls revenue from the analytics store, sales ops pulls it from the application database, and the numbers don't match. Both teams ran the right query. A batch of corrections landed in the primary after the last sync. Now two capable people spend the afternoon working out which copy is the truth, how stale the other one was and whose job it was to notice. Those are the three questions nobody answered when the copy went in. Everybody loves a reconciliation meeting. It compounds, too. Every new feature that reads from the copy or writes to it is one more decision left unmade. None of this depends on how good your pipeline is. A perfect pipeline still produces a copy, and a copy is still downstream of the truth. That's the platform tax worth worrying about: the one you pay when nothing is broken. ## When a second system is the right call Sometimes a separate system is the right answer. Bulk analytics over historical data, where nobody needs the results to reflect the last few minutes, can belong in its own system. A batch job crunching last year's numbers doesn't care that its copy is a few hours old, and keeping that work off your primary is reasonable. Replication can be a decision too. Plenty of systems copy data from where it's produced to where it's used, such as edge or regional databases feeding a central one. That works when the copy was designed that way: one side is clearly the source of truth, the lag is a number someone agreed to, and somebody owns keeping it right. In both cases, someone weighed it, wrote down why and knows what they gave up. If you're weighing that tradeoff right now, here's [a guide to choosing an analytical database](https://www.tigerdata.com/learn/how-to-choose-an-olap-database). ## What to do differently A split starts with one sentence: "let's put it in its own place." That's the moment to slow down long enough to make it a decision. When someone says it, write down three things: - What the source of truth is for this data, and how everyone will know which copy that is. - How stale the copy is allowed to be, as a number agreed on by the people who will query it. - Who owns the copy, including keeping it correct when the source changes. ![Decision tree. When someone says “let’s put it in its own place,” first ask whether the primary database can serve the need directly. If yes, serve it from the primary, with no copy to govern. If no, ask whether you can name the source of truth, the allowed staleness and the owner. If yes, add the system on purpose and write down the three answers. If no, you’re not ready to add the system.](https://assets.tigerdata.com/blog/2026/10/before-you-add-a-second-copy.png) If you can't fill those in, you aren't ready to add the system. Before any of that, ask the cheaper question: can the primary database serve this need directly? If it can, there’s no copy to govern, and you keep [everything one database gives you](https://www.tigerdata.com/blog/need-separate-time-series-database). Then go look at the splits you already have. For each one, ask whether you'd choose it again today, knowing what it costs. Some will be a yes. Keep those, and write down why. The rest are the ones you accumulated. ## Make the next one on purpose You don't choose a split architecture. You accumulate one. The way to end up with a split you actually chose is to make the next call on purpose, and that starts with knowing what your primary database can already do. So when analytics is the reason you're reaching for a second copy, check whether the primary can already do the job. For analytics on live data, that's what Hypercore is for. Tiger Data's hybrid row-columnar storage engine allows real-time analytics without sacrificing transactional capabilities, within a single database. [Read how Hypercore works](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore) before you add the next copy.