CelinQ Insights · No. 20

The hidden cost and fragility of shared-database EA repositories

What a central database repository really asks of you, and a lighter alternative.

There is a moment in the life of almost every architecture practice when the single-file repository stops being enough. It happens gradually and then all at once. For a while one person, or two, can share a model by passing a file around, and the friction is tolerable because it is intermittent. Then the team grows, the model grows with it, and the friction stops being intermittent. Two people want to edit at the same time. Someone overwrites someone else's morning. The file lives on a network share that is fast on a good day and unusable on a bad one. Eventually the conclusion feels inevitable: put the repository into a shared central database, give everyone a connection, and let the database sort out the concurrency. It is the standard move, it is well documented, and for a great many teams it is the right instinct pointed at the wrong solution.

The reason it feels right is that it genuinely solves the immediate pain. Concurrent access becomes possible. The awkward file-passing ritual disappears. Everyone points at one authoritative store and the problem that prompted the change is, in the narrow sense, gone. What the move does not advertise is everything it quietly signs you up for in exchange, and those obligations do not arrive as a bill on day one. They accumulate. They show up as operational work, as fragility, as performance that degrades in ways that are hard to attribute, and as a slow erosion of the working experience that nobody quite decided to accept. This article is about that trade — what a central database repository actually asks of you once the honeymoon ends, and why a lighter arrangement is worth considering before the heavier one hardens into permanence.

The obligations nobody quotes you upfront

A shared database is a piece of production infrastructure, and the moment your model lives inside one, your model inherits every responsibility that comes with running production infrastructure. Somebody has to provision the server and size it, and sizing is guesswork early on because you do not yet know how the model or the team will grow. Somebody has to secure it, which means network rules, credentials, patching, and a defensible answer when a security review asks who can reach it and how. Somebody has to back it up, and — this is the part that gets skipped — somebody has to prove that the backups actually restore, because an untested backup is a rumour, not a safety net. Somebody has to monitor it, tune it when it slows down, and be reachable when it stops. Somebody has to manage the upgrades of the database engine itself, each of which is a small act of faith that the repository on top will still behave afterwards.

In a large organisation with a mature database team, some of this is absorbed into work that is already happening, and the marginal cost looks small. But architecture repositories have an awkward habit of falling between stools. They are too important to be ignored and too specialised to be well understood by a general database team who have never opened the modelling tool and do not know what a healthy repository looks like from the inside. So the operational burden lands somewhere ambiguous — often on the architects themselves, who did not sign up to be database administrators and are not equipped to be, or on a central team who treat the repository as just another schema and are blindsided when it behaves unlike the transactional systems they are used to. Either way, the cost is real, it is ongoing, and it was never in the estimate that justified the move.

Fragility that hides in the middle of the network

The deeper problem with a central database repository is not the administrative overhead, which at least is visible once you go looking for it. It is the fragility that comes from putting a single, always-required dependency in the middle of everyone's working day. When the authoritative model lives in one place and every architect's ability to work depends on a live connection to that place, you have created a shared fate. The server, the network path, the credentials, the firewall between the architect and the database — every link in that chain is now a link between an individual's productivity and forces entirely outside their control.

This shows up in ways that are individually small and collectively corrosive. A network hiccup stalls an edit. A brief server restart during business hours empties the room. An architect working from a client site, or from home, or from a train, finds that the thing standing between them and their own model is a database port that the local network has strong opinions about. Latency, in particular, is a silent tax: every interaction that has to make a round trip to a central server is a little slower than a local one, and while any single delay is beneath notice, the sum of them across a day is the difference between a tool that feels like an extension of your thinking and one that feels like something you are negotiating with. None of these are catastrophes. That is exactly why they are dangerous. Catastrophes get fixed because they demand attention; a steady drip of small friction just becomes the ambient temperature of the job, quietly discouraging people from opening the model as often as they should.

The false economy of "we already have a database team"

One argument for the central-database route deserves a direct answer, because it is the one most often used to end the discussion: the organisation already runs databases, already has people who look after them, so putting the repository there costs nothing extra. It sounds unanswerable and it is mostly wrong, for two reasons that only become clear later.

The first is that an architecture repository is not a typical database workload, and the expertise that keeps transactional systems healthy does not transfer cleanly. The access patterns are different, the shape of the data is different, and the failure modes that matter are different. A general database team, entirely competent at what they normally do, can look after the repository server perfectly well and still miss the things that actually degrade the modelling experience, because those things are invisible from where they sit. The repository ends up in a gap: technically supported, practically unowned by anyone who understands it from the modelling side.

The second reason is subtler and more expensive. Putting the repository into the shared database estate makes it a dependant of that estate's decisions. When the database team schedules maintenance, your architects lose access on the database team's calendar, not their own. When a security policy changes, your repository is subject to it whether or not it makes sense for a modelling workload. When the estate migrates, upgrades, or consolidates, your model is carried along for reasons that have nothing to do with architecture and everything to do with someone else's priorities. The "free" infrastructure turns out to have a governance cost: you have handed control of your most important architectural asset's availability to a team whose goals are not your goals. That is not a saving. It is a transfer of control that happens to be free at the point of sale.

Concurrency was the real question all along

It is worth stepping back to notice what the central database was actually being asked to solve, because the whole escalation rests on it. The original pain was concurrency: several people needing to work in the same model without destroying each other's work. The central database answers that question by making everyone edit the same live store, which does prevent the crude file-overwrite problem but replaces it with a subtler one. When many people edit a shared live store, the model is only ever as coherent as the last set of interleaved changes, and the tool's ability to keep those changes from colliding becomes the thing everyone quietly depends on and nobody examines. The concurrency problem was not so much solved as relocated into the database, where it is harder to see.

There is a better framing of the same question. What a team actually needs is not for everyone to be typing into one live store at the same instant. It is for everyone to be able to work productively in parallel and for their work to come together reliably, without loss, and without anyone having to arbitrate who was editing what at 11:40 on Tuesday. Framed that way, the central live store is only one possible answer, and not obviously the best one, because it buys parallel work at the price of a shared, always-on dependency and a merge behaviour that most teams never actually inspect until it hurts them.

A lighter arrangement

CelinQ takes the other answer. Instead of pulling everyone into one live store, it lets each architect keep a complete local repository and edit it at full native speed, online or offline, working alongside Sparx Enterprise Architect exactly as before. A background companion syncs each save with a shared workspace that the organisation runs itself. The parallel work happens locally, where it is fast and where nothing outside the room can slow it down or take it away, and the coming-together happens through synchronisation rather than through everyone crowding into the same connection.

The part that makes this safe rather than merely fast is how the coming-together is handled. CelinQ's merge engine, CelinQ Fusion, performs a deterministic, reproducible three-way merge at the granularity of individual model facts. That granularity is the whole point: rather than reasoning about whole files or whole diagrams, it reconciles the specific facts that changed, so two people working in different corners of the same model combine their work cleanly instead of contending for the same lock. It uses tombstones to represent deletions properly, so a thing one person removed does not quietly reappear because someone else touched something nearby. And crucially, it never resolves a genuine conflict by silently letting the last writer win. Real conflicts are isolated and made explicit so that a person decides them, rather than the system guessing and someone discovering the guess was wrong three weeks later. Because the merge is deterministic and reproducible, the same inputs always produce the same result, which means the behaviour can be reasoned about and trusted rather than treated as a black box you hope stays lucky.

Around that engine sits the machinery a serious team needs without the machinery a serious team dreads. There is a complete, ordered revision history, so the full record of how the model reached its current state is always available rather than flattened into a single live snapshot. There are roles — Viewer, Editor, Administrator, Owner — so authority over the model is explicit. There is change review and governance for teams that need to see and approve what is entering the shared workspace, and lightweight presence so people have a sense of who else is around without that awareness becoming a tax. The synchronisation cadence adapts through Smart Sync rather than hammering the server on a fixed timer. Transport is encrypted with certificate pinning, and access runs through token authentication. None of this depends on standing up and babysitting a heavyweight central database.

Storage that matches the team, not the other way around

The shared workspace does need somewhere to live, and this is where the contrast with the central-database route is sharpest. CelinQ stores the workspace on either SQLite, for a small team that wants essentially nothing to administer, or PostgreSQL, for a larger deployment that wants the concurrency and operational tooling of a full engine — and both sit behind the same interface. A small team does not have to conjure a database server into existence and then find someone to look after it just to collaborate. A larger organisation is not denied a proper engine when it genuinely needs one. And because the two backends share one interface, the decision is not a one-way door: a team can start light and move to the heavier engine when the size of the team, the volume of history, or a security policy makes that the right call, without rebuilding how they work.

The difference from the traditional escalation is that the storage engine here is serving the team's current shape rather than dictating it. In the central-database model, the decision to adopt a heavy engine is made early, under pressure, when the team is often at its least able to judge what it will need, and the decision then hardens because unwinding it is a project. In this arrangement the engine is a setting that follows the team, chosen to fit where the team actually is and changeable when the team moves. The obligation to run production database infrastructure — with all the provisioning, securing, backing up, monitoring, and tuning that entails — becomes something you take on deliberately when scale warrants it, not the entry fee for letting three people edit a model together.

What the central store hides from view

One of the quiet virtues of moving the reconciliation into an explicit, inspectable process is that it stops hiding the coordination that a central live store buries. In the central-database arrangement, the way concurrent changes interleave is a property of the database and the tool sitting on top of it, and it is almost never examined until something goes wrong. Teams run for years on an arrangement whose behaviour under contention they have never actually tested, trusting that the store will do the right thing because it has not visibly done the wrong thing yet. That is not confidence; it is the absence of a bad experience, which is a very different and much more fragile thing. The first time two people's changes interleave badly, the team discovers all at once how little they understood about the mechanism they had been depending on.

An explicit, deterministic merge turns that hidden mechanism into something a team can actually reason about. Because the reconciliation happens at the granularity of individual model facts and produces the same result from the same inputs every time, its behaviour is not a matter of luck or timing. A team can understand what will happen when two people edit near each other, can trust that a deletion stays deleted, and can know that a real conflict will be raised rather than silently resolved. None of that visibility is available when the coordination is submerged inside a shared live store. The central database does not make the concurrency problem go away; it makes it invisible, and invisible problems are the ones that eventually cost the most, because they are discovered at the worst time and by the least prepared person.

This is also why the operational fragility and the coordination fragility are really the same story told twice. A central store concentrates both the running of infrastructure and the reconciling of changes into one always-on component that everyone depends on and few understand from the inside. Pull either of those apart from the central store — let editing be local, let reconciliation be an explicit and reproducible process, let the storage engine be proportionate to the team — and the concentration of risk dissolves. The team is no longer betting its daily productivity and the integrity of its model on a single piece of infrastructure behaving well under conditions nobody has tested. It is a lighter arrangement not because it does less, but because it stops asking one component to silently carry so much.

The honest limits

None of this makes coordination free, and it would be a poor argument that pretended otherwise. When people work in parallel and reconcile afterwards, genuine conflicts still happen — two people really do sometimes change the same fact in incompatible ways — and someone still has to decide. The difference is not that conflicts vanish; it is that they are surfaced honestly and put in front of a human instead of being resolved by whoever happened to save last. That is more work than pretending conflicts do not exist, and it is far less work than discovering weeks later that a decision was quietly lost. A team that expects the model to reconcile itself with no human judgement anywhere will be disappointed by any honest tool, and should be suspicious of any tool that promises otherwise.

There is also a class of very large, heavily concurrent deployment where a full database engine and dedicated operational care are simply the right answer, and nothing here argues against that. The argument is against reaching for the heaviest possible arrangement reflexively, as the default first step, when the team is small and the real requirement is modest. The lighter path is not a claim that databases are bad. It is a claim that infrastructure should be proportionate to need, that the option to scale up should stay open, and that a team should not pay the full operational price of a central database on the day they have three architects and a model that fits comfortably in something far simpler.

A grounded takeaway

The shared central database is the reflexive answer to the concurrency problem, and reflexes are worth pausing on precisely because they skip the question. Before your practice signs up for a piece of always-on production infrastructure and everything that comes with owning it — the provisioning, the securing, the backups you have to test, the monitoring, the tuning, the shared fate with a database team whose priorities are not yours — it is worth asking whether the thing you actually need is a central live store at all, or simply a reliable way for people to work in parallel and have their work come together without loss.

If it is the latter, a lighter arrangement can deliver it with far less fragility. Editing stays local and fast, independent of the network's mood. The coming-together is handled by a deterministic merge that isolates real conflicts instead of guessing at them. The full history, the roles, and the governance are all present. And the storage underneath fits the team you have today while leaving the door open to the engine you might need tomorrow. That is not a rejection of databases. It is a refusal to let the choice of database become the first and heaviest decision a growing practice is forced to make — and a way to keep the operational weight proportionate to the problem it is actually solving.