CelinQ Insights · No. 19

Avoiding lock-in: your model, your database, your choice

Staying free to move between storage backends and deployments.

Lock-in is rarely a decision anyone makes on purpose. Nobody sits in a procurement meeting and says, out loud, that they would like to spend the next decade unable to move their most important architectural asset without a migration project. It happens the other way around: through a hundred small, reasonable conveniences that each seemed harmless at the time and that, taken together, quietly weld the model to a particular vendor, a particular database, a particular way of working. By the time anyone notices, the cost of leaving is high enough that leaving stops being discussed. That is the trap, and the reason it is worth thinking about early is that the only cheap moment to avoid it is before you are inside it.

For an enterprise architecture practice the stakes are unusually high, because the repository is not a peripheral tool. It is the accumulated understanding of how the organisation actually works: which capabilities depend on which applications, which applications ride on which infrastructure, which decisions were taken and why, which obligations flow from which regulations. That understanding took years to assemble and it is meant to outlive the projects that produced it, the consultants who contributed to it, and very possibly the software that currently holds it. A model that cannot be moved is a model that has been made hostage to whatever platform happens to hold it today, and platforms have a way of changing hands, changing licences, and changing prices on a schedule that has nothing to do with your own.

What lock-in actually looks like

It helps to be concrete, because lock-in is not one thing. There is format lock-in, where your content lives in a proprietary shape that only one product can read, so leaving means an export that loses fidelity and a re-import that never quite lands. There is database lock-in, where the repository is bound to one specific database engine, and the engine you chose when the team was small turns out to be the wrong one when the team is large, but the binding is so tight that changing it is a project in its own right. There is deployment lock-in, where the whole thing only runs as a hosted service you do not control, so your ability to keep working depends on someone else's uptime, someone else's roadmap, and someone else's willingness to keep the lights on at a price you can afford. And there is the quietest form of all, workflow lock-in, where the way your people collaborate has been shaped so thoroughly by one product's assumptions that even a technically clean migration would strand years of habit.

Each of these has a cost that stays invisible right up until the moment it doesn't. The database binding costs nothing until the day the team outgrows the engine, or the day a security review rules that engine out, or the day the licensing terms change and the finance conversation suddenly involves people who have never opened the repository. The hosting binding costs nothing until an outage lands in the middle of a delivery, or a data-residency requirement arrives that the hosted option cannot satisfy, or the service is quietly deprecated and you are handed a migration deadline you did not choose. These costs do not announce themselves in advance. They arrive as emergencies, and emergencies are the most expensive possible moment to discover that you cannot move.

The Sparx repository, and where the pressure builds

Teams working in Sparx Enterprise Architect know this terrain well, because the repository question is a live one from the first day of any serious deployment. A single-file repository is wonderfully simple for one person and becomes a source of friction the moment several people need to work in it at once. The usual escalation is to move the repository into a shared central database so that everyone can connect to the same store. That solves the immediate concurrency problem, and it introduces a new dependency in the same motion: the model now lives inside a database server that has to be provisioned, secured, backed up, tuned, and kept available, and the model is now bound to whichever engine that server runs.

None of that is a criticism of Sparx, which is a capable and long-lived tool. It is simply the shape of the problem. Once the repository is central, the health of the model is coupled to the health of a piece of infrastructure, and the choice of infrastructure tends to calcify. The engine you picked in the first month becomes the engine you are still running years later, not because it is still the right one but because the model is now inside it and getting it out again is nobody's idea of a good quarter. The pressure builds slowly and it builds in one direction: toward staying put.

A different starting assumption

CelinQ starts from a different assumption, which is that the storage engine is an implementation detail and should be treated as one. It works alongside Sparx Enterprise Architect rather than replacing it, so every architect keeps editing a local repository at full native speed, online or offline, exactly as they do now. What changes is what happens underneath. A background companion syncs each save with a shared workspace on a server the organisation runs itself, and that shared workspace can sit on either of two storage backends behind one and the same interface. A small team can run on SQLite and have essentially nothing to administer. A larger deployment can run on PostgreSQL and get the concurrency, operational tooling, and scale that a bigger organisation expects. The point that matters for lock-in is that both sit behind the same interface, so the choice between them is not a fork in the road you can only take once.

That design decision is doing more work than it first appears. When the backend lives behind a stable interface, moving from one to the other becomes a supported operation rather than a migration adventure. A team can start small, on the lighter engine, because starting small is genuinely the right call when a team is small and the overhead of a full database server would be pure ceremony. Then, when the team grows, or when a security policy tightens, or when the sheer volume of history and concurrent editing argues for a heavier engine, the team can move to PostgreSQL without rebuilding the way they work and without renegotiating their relationship to their own model. The engine changed. The workspace, the history, the roles, the habits, all of it carried across. The decision you made when you were small did not turn into a sentence you have to serve now that you are large.

Local-first is itself an anti-lock-in stance

There is a deeper reason the local-first design resists lock-in, and it is worth drawing out because it is easy to miss. In a central-database arrangement, the authoritative copy of the model exists in exactly one place, and your ability to work is a function of your connection to that place. If the server is down, or the network is out, or you are on a train, or you are at a client site behind a firewall that does not love your database port, you are stuck. The single central store is not just a scaling concern; it is a single point of dependency that reaches all the way into whether an individual architect can do their job on a given afternoon.

Local-first inverts that. Each architect holds a complete, working local repository and edits it at full speed regardless of connectivity. The shared workspace is where those local repositories reconcile with one another, but it is not the thing standing between an architect and their own work. This matters for lock-in because it decouples daily productivity from the availability and identity of any particular server. The model is not trapped inside one machine that you must keep paying to reach. It lives, in complete form, close to the people using it, and the shared workspace is a service that reconciles those copies rather than a vault that holds the only one. A dependency you can survive losing for an afternoon is a dependency that has far less power over you.

Sovereignty as a first-class property

For the kind of organisation that takes its architecture seriously — public-sector bodies, regulated industries, anyone with a data-residency obligation or a genuine reason to keep their internal understanding of themselves under their own roof — the question of who controls the repository is not a technicality. It is close to the whole point. An architecture model describes, in structured detail, how an organisation is put together and where its dependencies and weaknesses lie. That is precisely the kind of asset you do not want to discover, at an inconvenient moment, that you cannot fully account for because part of it lives on infrastructure you neither own nor control.

CelinQ is built so that everything can stay under the organisation's control. The shared workspace runs on a server the organisation runs itself. Transport between the companion and that server is encrypted, with certificate pinning so that the client will only talk to the server it is supposed to talk to, and access is controlled through token authentication and a clear set of roles — Viewer, Editor, Administrator, Owner — so that who can do what is an explicit decision rather than an accident of who happened to have the connection string. The core of the product needs no external service to function. There is an optional design assistant that lives inside EA and can generate content into a selected package or analyse existing parts of the model, but it is off by default, it is sovereign, and the core works completely without it. Nothing about the way the product is built requires you to route your model through anyone else's premises to get value out of it.

The reason this belongs in a discussion of lock-in is that sovereignty and portability are the same virtue seen from two angles. A model you fully control is a model you can move, because moving it does not require anyone's permission or cooperation beyond your own. A model that depends on an outside service to function is a model whose portability is only ever as good as that service's willingness to let you leave, and the history of hosted software is not overflowing with examples of that willingness being generous. Keeping the whole thing under your own control is not merely a compliance box. It is the mechanism by which the exit door stays unlocked.

Portability you can actually exercise

It is easy to claim openness and harder to make it real. The honest test is not whether a product's marketing uses the word, but whether the things you would need to do in an exit are ordinary supported operations or heroic one-offs. Can you move between storage backends without rewriting how the team works? Can you stand the server up on your own infrastructure without depending on a vendor's cloud? Can you get at the complete, ordered history of every change rather than a flattened snapshot? Do the roles and the governance around change travel with the model, or are they a property of some external console you would lose access to the moment you left? These are the questions that decide whether portability is a genuine property or a brochure adjective.

CelinQ's answers to those questions are structural rather than promotional, which is the part that should reassure a skeptic. The two backends sit behind one interface specifically so that moving between them is a normal thing to do. The server is one you run, so standing it up elsewhere is within your gift and not a favour you have to ask. The complete ordered revision history is a core feature, not an add-on, so the full record of how the model came to be what it is stays with the model. And the roles, the change review, and the governance are part of the workspace, so they are not a rented layer that evaporates on the way out. None of this is offered as a promise about intentions. It is a description of how the thing is put together, and how it is put together is what you are actually relying on when the day comes that you need to move.

The honest caveats

It would be dishonest to pretend that any tool makes lock-in impossible, and the point of this article is not to sell that fantasy. Every serious system creates some gravity. The moment a team has years of history, an established set of roles, a rhythm of change review, and a body of habit built around a particular way of collaborating, there is a real cost to changing any of it, and that cost is not zero no matter how open the underlying storage is. What a good design can do is make sure the gravity is concentrated in the things that genuinely should be sticky — the model itself, the history, the shared understanding — and kept out of the things that should never have become sticky in the first place, like the choice of database engine or the identity of a hosting provider.

That is the distinction worth holding onto. Some stickiness is the natural weight of an asset you have invested in for years, and you would not want that asset to be so weightless that it blew away. But the stickiness of a database binding, or a hosting arrangement, or a proprietary format, is different in kind. It is friction that serves the platform rather than the practice, and it is the kind that turns into an emergency at the worst possible moment. The goal is not the impossible one of a system with no gravity at all. The goal is a system whose gravity is aligned with your interests instead of quietly working against them.

Lock-in is a slow tax on your future decisions

There is one more way to think about lock-in that tends to land with architects in particular, because it is the way we habitually think about everything else. Lock-in is a form of coupling, and coupling is the thing our whole discipline exists to manage. We spend our careers arguing that systems should depend on stable interfaces rather than on each other's internals, that a change in one place should not ripple uncontrollably into another, and that the ability to replace a component without rebuilding everything around it is worth designing for even when no replacement is currently planned. All of that wisdom applies to the repository that holds the models just as much as it applies to the systems the models describe, and yet the repository is the one place we routinely forget to apply it.

Seen that way, a tight binding between your model and a particular database engine, or a particular hosting arrangement, is exactly the kind of coupling we would flag as a risk in any system we were reviewing. It is a dependency on a volatile detail dressed up as a dependency on a stable one. Engines change, licences change, hosting providers change, and the organisation's own policies about where data may live change more often than any of them. Every one of those changes becomes a forced decision the moment your model is welded to the thing that changed, and forced decisions are always made on someone else's timetable, usually under pressure, and rarely well. The tax lock-in levies is not really the migration project you eventually have to run; it is the years of smaller decisions you make badly in the meantime because the good option was quietly off the table.

The value of keeping the storage engine behind a stable interface, of running the server yourself, and of holding the complete history close is that it converts those forced decisions back into free ones. When the engine is a setting rather than a sentence, the day a security review rules against your current database is an afternoon's change of configuration, not a quarter's worth of migration and risk. When the server is yours, a change in someone else's roadmap is not a change in your plans. The freedom is not abstract. It shows up as the ordinary ability to keep making good decisions on your own schedule, which over a decade is worth far more than any single migration you avoid.

A grounded takeaway

The practical advice that falls out of all this is not dramatic, which is usually a sign that it is right. When you choose how your architecture repository will live, treat the storage engine and the deployment as things you should be able to change your mind about, because sooner or later you will. Favour arrangements where the model, its full history, and the governance around it stay under your own control and travel together, and be suspicious of any convenience that can only be enjoyed by giving up the ability to leave. The convenience is real; it is just rarely worth what it quietly costs.

It is worth saying plainly that this is a stance, not a feature, and stances are what survive when features are forgotten. A team can add and remove features indefinitely without ever changing the fundamental question of who controls the asset and whether it can be moved. That question is settled by architecture — by where the authoritative copies live, by whether the storage sits behind a stable interface, by whether the server is yours — and once it is settled well it keeps paying off in situations nobody anticipated when the choice was made. The organisations that stay free are rarely the ones that negotiated the best exit clause. They are the ones that never let the exit become something they would have to negotiate in the first place.

CelinQ was built around that instinct. Editing stays local and fast, the shared workspace runs on infrastructure you own, the storage backend is a choice you can revisit as the team changes rather than a decision that hardens into a constraint, and the whole thing can operate without reaching out to anyone else's service. The result is not a promise that you will never want to move. It is the more useful thing: the assurance that when you do want to move, whether between backends, between scales, or away from CelinQ entirely, you will be moving something that was yours the whole time. Your model, your database, your choice — kept that way by design rather than by goodwill, which is the only form of that promise worth relying on.