Beyond Digital Feudalism: Architecting for Data Sovereignty

From the twelfth and thirteenth centuries, peasants on many European manors were bound by custom or charter to grind their grain at the lord's mill, bake at his oven, and press at his winepress. These mandatory use-fees, the banalités of French law, were not income taxes. They were tolls on transactions you had no legal right to perform elsewhere.

Towns escaped banalities the same way: by negotiating a charter directly from the lord or the crown. A chartered town could hold its own markets, run its own mill, elect its own officials. It paid for the right to stop paying. That trade is the analogy I want to use for the rest of this post.

This pattern repeats. Whilst a market frontier is open, platforms continue to compete on capability. Once enough customers are inside, the centre of gravity shifts toward extracting value from the relationships already sunk in. Shapiro and Varian wrote about the lock-in lifecycle in 1999; the cycle has not changed.

The chart below tracks that shift: the horizontal axis is time as a market matures from open frontier to saturation. The two curves represent where the platform is spending its energy: one tracks investment in new capability (features that win net-new deals), the other tracks switching-cost monetisation (egress fees, proprietary surface area, renewal pricing power). Early on, capability dominates; somewhere past saturation the curves cross and the second one takes over. Most enterprise data platforms have already passed that line.

The platform lifecycle: capability competition whilst the frontier is open, switching-cost monetisation once it is settled.

Mechanical Rock partners with both Snowflake and Databricks and recommends them on most client builds. This post is about what to architect for after that first build has paid off and the estate has grown past a single-platform fit.

The Digital Manor

The cloud platform market has matured. Snowflake, Databricks, and the hyperscalers are no longer winning new deals on raw capability alone. The competitive frontier has shifted to depth of integration and the value customers accumulate inside the ecosystem over time.

The most visible banality is egress: data moves in freely, but moving it out carries a price. The less visible banality is logical lock-in. Business logic written in vendor-specific SQL dialects and proprietary stored procedures creates a contingent migration liability: an unrecognised switching cost that doesn't appear on the balance sheet, but influences every renewal negotiation.

Consider the Snowflake Dynamic Table, which appears in almost every estate I work in. It doesn't port to Databricks, BigQuery, or Postgres without a rewrite. The same applies to most of Snowflake's proprietary SQL surface area: OBJECT_AGG, HASH_AGG, stored procedures, custom UDFs. Repeat that pattern across hundreds of models and those platform-specific choices gradually weld the workloads to the warehouse.

Visible OPEX (operating expenditure, the recurring SaaS invoice that hits the P&L each month) grows linearly whilst the contingent exit cost compounds exponentially. Switching-cost framing from the vendor lock-in.

What hyperscalers and warehouses are modelling here is well-described in the economics literature. They are not extracting Ricardian rents (where rent is equal to best economic use of land) from a scarce natural resource. They are capturing quasi-rents on the relationship-specific investments the customer has already made: the dbt models, the stored procedures, the operational runbooks. The mechanism changed from manorial law to commercial contract, but the underlying economics, value flowing from accumulated investment, has the same shape across centuries.

The Compounding Company Town

In the Pilbara, the iron ore majors built closed company towns like Tom Price and Newman in the 1960s. The model was highly efficient for rapid deployment, but the dependency was strict enough that Karratha was established in 1968 as a deliberately open town under a state agreement, where anyone could live, not just iron-ore workers. The closed-town model was eventually unwound through FIFO arrangements over the following decades.

A digital company town operates on a more aggressive feedback loop. A physical mine depletes faster than its switching costs accumulate; the asset shrinks whilst the surrounding lock-in stays roughly constant. A data estate runs the other way. The underlying information depreciates (schema drift, semantic decay, retention obligations under the Australian Privacy Principles, Australian Taxation Office record-keeping rules, and the General Data Protection Regulation), but the lock-in liability compounds faster than the depreciation can offset it. The financial gap widens.

Snowflake and Databricks offer world-class compute engines. Tightly coupling logic to their native features delivers immediate value, secures organisational buy-in, and is the right call when the team is two engineers and a deadline. The bias toward vendor-native is not irrational short-termism; it is a rational response to OPEX-favourable accounting treatment (SaaS spend hits the P&L without the capitalisation work of internally developed software) and to CIO tenure horizons of around four years against lock-in curves of seven to ten.

The Chartered City

The medieval town did not escape the manor by destroying the mill. It negotiated a charter that let it run its own. The same move applies to data architecture.

Split the data from the engine and the engine becomes negotiable. Cloud platforms get to solely focus on their world-class, focused compute. You use that compute, and you hold the charter on your assets: the storage, the catalog, the dialect, and the operational logic that sits on top.

Sovereign architecture isn't about avoiding vendors. It's about grounding the relationship in the value the platform delivers, not in the cost of leaving it.

Snowflake and Databricks have both moved decisively toward open formats over the last two years, Polaris and Iceberg-first features from Snowflake, Unity OSS and UniForm from Databricks. The sovereign architecture this post describes is not opposed to those platforms; it is the architecture they are themselves building toward. The question is whether your estate gets there alongside them or after them.

Snowflake and Databricks did not start from the same place. Databricks has always written customer-owned Delta files into customer-owned blob storage; the lock-in lives in Unity Catalog and runtime-specific features layered on top, not in where the bytes physically sit. Snowflake historically kept the bytes inside its own service account in a proprietary micro-partition format, and has only recently treated Iceberg tables and Polaris catalog as first-class options. The direction of travel is converging on open formats with vendor-managed convenience on top, but the starting point matters for how much sovereignty work an existing estate still has in front of it.

Architectural mobility against five-year TCO. Vendor-locked tooling and sovereign architecture sit at opposite corners of a Pareto frontier.

Cloud platforms can then drop into the role they should have been playing all along: interchangeable utilities. At renewal, you have a walk-away option, which is the only kind of negotiation leverage that survives a CFO review.

Where Sovereignty Costs More

The main costs of sovereignty:

• Higher up-front cost. Open table formats and self-managed catalogs require more architectural design and engineering time than buying into Snowflake or Databricks on day one.
• Performance ceiling. Vendor-managed proprietary formats still outperform open formats on certain workloads (highly concurrent dashboards, complex pruning patterns). Closing that gap is a multi-year arc.
• Operational maturity. You have to actually run the catalog, the file lifecycle, and the access controls. If the team cannot do this well, you have traded one form of risk for another.

If a project is six months old, has three data engineers, and a CEO who needs the dashboard live this quarter, vendor-native is the right call. Sovereignty is a strategy you grow into as the estate matures and the contingent liability compounds past one platform's natural fit.

Takeaways

1. Treat data as a financial asset, not a feature. The cost is on the balance sheet whether the CFO sees it or not. Architects who can speak to that get listened to.
2. The lock-in is in the logic, not the storage. Egress fees are a rounding error compared to rewriting business logic out of a vendor dialect.
3. Open formats are the shipping container of the digital era. Iceberg, Delta, and Parquet reduce the transaction cost of switching engines, which is the lever that brings vendors back to the negotiating table.
4. Sovereignty is a maturity decision, not a moral one. Buy vendor-native for the first project. Refactor toward open formats when the estate compounds past one platform's natural fit.

Wrapping Up

Architectural resilience in a mature cloud market is defined by mobility. Treat the data estate like a balance-sheet asset, not a sunk-cost tool selection, and the renewal conversation looks completely different.

If you are staring down a renewal cycle and finding the exit options uncomfortable, or you are about to start a new platform build and want to design for optionality from day one, feel free to reach out to me or Mechanical Rock. We treat long-term cost predictability as a deliverable.

---

Appendix: Historical Parallels

The economic mechanics of cloud architecture map cleanly to three historical precedents:

• The US Transcontinental Railroad (1870s–80s). Maps to the lifecycle of network-effect monopolies. The 1860s build phase was largely funded by federal land grants. By the 1870s and 1880s, with the network largely built, the business model shifted to rent extraction: rebates to favoured shippers, discriminatory long-haul and short-haul rates, and pooling arrangements. The Granger Laws and the Interstate Commerce Act of 1887 were responses to that shift. Innovation did not stop (refrigerated cars and air brakes both arrived in this period), but the centre of gravity moved decisively from construction to monetisation of the captive freight base.

• The COBOL Mainframe Trap (1960s–70s, visible by the 1990s). Maps to the compounding contingent migration liability. Decades of core business logic accreted in proprietary COBOL on IBM mainframes from the 1960s onward. The lock-in was not visible at the time because the alternatives (minicomputers, C, relational databases) had not yet matured. By the late 1990s, Y2K remediation alone ran into hundreds of billions in global spend, and subsequent regimes (SOX in 2002, Basel II from the mid-2000s) compounded the cost of every line that could not be safely refactored.

• Containerisation of Maritime Freight (1956–70). Maps to the Pareto improvement that open formats deliver. Malcom McLean's Ideal-X sailed in 1956, but it took more than a decade of standards fights, culminating in ISO 668 (1968–70), plus the demand shock of US military logistics in Vietnam and bitter dockworker disputes, before cargo became genuinely interchangeable across crane, ship, and truck. Once it did, mobility exploded and transaction costs collapsed. Iceberg, Delta, and Parquet are the ISO container moment for compute.