Why boards and issues belong on one schema

Open a kanban board and an issue tracker side by side and squint. The board has cards with a title, an assignee, a status column, maybe a label. The tracker has issues with a title, an assignee, a state, some labels. They look different because they're styled for different audiences — but underneath, they're describing the same thing: a unit of work that has a state and moves through it. The industry sells them as two products because they're sold to two buyers, but that's a marketing fact, not a technical one.

What separate systems cost you

When the board and the tracker are genuinely separate systems, you're maintaining two sources of truth for one reality, and the integration between them is where your week goes. A card moves on the board; a sync job — eventually, maybe — moves the issue. The two drift whenever the sync lags, errors, or hits a field one side has and the other doesn't. Now 'what's the status of this work?' has two answers, and reconciling them is a standing tax on everyone who touches both tools.

It gets worse at the edges. The board has a concept the tracker doesn't — a swimlane, a WIP limit — and there's nowhere to put it on the other side, so it's lost in translation. An issue has a parent-child relationship the board flattens. Each integration is a lossy projection of one model onto another, and lossy projections leak. The bugs you spend the most time on aren't in the board or the tracker; they're in the seam between them.

One schema, many views

Put the work on one schema and the board and the tracker become what they always were: two views of the same row. A card on a board and an issue in a list are the same record, rendered two ways. Moving the card changes the state; the list reflects it in the same instant because there's nothing to sync — it's the same data. The swimlane and the parent-child link and the WIP limit all live on the one model, available to whichever view wants to show them, lost by none.

This is the architecture that makes consolidation real instead of cosmetic. A 'unified' tool that's secretly two databases with a sync job has just hidden the seam, not removed it — you'll find it again the first time the sync hiccups. A genuinely unified tool has one model and renders it however each role needs to see it: board for the column-thinkers, list for the queue-thinkers, timeline for the quarter-thinkers, all reading and writing the same rows.

Why this is a data-model decision, not a UI one

The temptation is to treat 'board vs. tracker' as a front-end problem — build both UIs, wire them to whatever backend, ship. But the unification has to happen in the data model or it doesn't happen at all. If the board and the tracker resolve to different tables, no amount of front-end polish closes the gap; you've just built two products that look like one. If they resolve to the same table, the front-end choice is trivial and the consistency is free, because there's only one thing to be consistent with.

That's the case for getting the schema right before the pixels: the data model is the product. Boards and issues belong on one schema not because it's elegant, but because every property anyone values about a unified tool — instant consistency, no drift, no lossy sync, one honest answer to 'what's the status' — falls directly out of that single decision, and none of them are recoverable later if you decide it wrong.

What 'one schema' actually buys at the feature level

The abstract case is convincing, but the payoff is most obvious in the features that become trivial. Bulk operations: select fifty cards on a board and change their assignee, and because they're the same rows the tracker queries, the list, the timeline, and every report reflect it instantly — no sync to wait on, no view left stale. Cross-view filtering: a saved filter written against the model works identically whether you render it as a board, a list, or a roadmap, because it's filtering the data, not the presentation. Permissions: scope access once on the model and every view inherits it, instead of bolting separate access rules onto a board product and a tracker product and praying they agree.

These aren't features you build; they're features you get. That's the tell of a good data-model decision — the surface area of new work shrinks because each capability you add to the model lights up in every view at once. On separate systems, every one of those features is a project with an integration tax. On one schema, they're a query.

The cost of getting it wrong is paid forever

It's worth being blunt about the stakes, because schema decisions are the ones you can't cheaply revisit. If you launch board and tracker as separate tables and later want to unify them, you're not refactoring a component — you're migrating live customer data, reconciling two histories that diverged, and untangling every integration that assumed the seam was there. Teams that try usually give up and ship a 'unified view' that's a read-only join over the two systems, which papers over the symptom and keeps the disease. The drift, the lossy sync, the two answers to one question — all still there, just hidden behind a nicer screen.

Get it right at the start and none of that exists to fix. Boards and issues on one schema is the kind of decision that's invisible when it's correct and inescapable when it's not. You'll never thank the data model on a good day, because everything that's supposed to be consistent simply is. You'll curse it on every bad day if you split it, because everything that's supposed to be consistent is one sync job away from a lie. That asymmetry is the whole argument: cheap to do once, ruinous to undo, and quietly load-bearing for every feature you'll ever ship on top of it.