Who Actually Owns an Iceberg Table? Managed, External, and the New Vocabulary of Lakehouse Control

Two architects are arguing in a design review about whether to use “managed” Iceberg tables, and the argument is unresolvable, because they are using the same word for different things. One means tables whose storage the platform provisions and whose compaction the platform runs. The other means tables the platform’s catalog governs, wherever the bytes live and whoever maintains them. Both usages are real, both appear in official documentation, from different vendors, both architects can cite their sources, and the meeting ends with an action item to “clarify the managed table question,” which is this article’s job description.

The confusion is not carelessness, it is a category outgrowing its vocabulary. When one vendor’s warehouse held your tables, ownership was a single fact with a single name. Iceberg unbundled the warehouse, storage from catalog from compute from maintenance, and ownership unbundled with it, into separate questions that the old words, managed, external, and their growing family of cousins, now compress lossily, with each platform compressing differently. So this article does the unbundling explicitly: five separable dimensions of table ownership, a translation method for any vendor’s vocabulary into those dimensions, how the REST catalog era reshuffles the answers, a decision framework for which posture each class of table deserves, what each posture costs at exit, and the failure modes that occur precisely where two systems each believe they own something.

Disclosure up front, and unusually relevant to this topic: I work at Dremio, whose Open Catalog is built on Apache Polaris, and I co-authored O’Reilly’s books on Apache Iceberg and Apache Polaris. Every platform’s terminology below is described structurally rather than judged, because the article’s claim is that the structures are comparable even where the words are not.

How the Words Got This Confusing

A short history explains the mess better than complaints about it.

”External table” is the oldest word in the room, inherited from the warehouse era, where it meant data the warehouse can query but did not load: your files, your formats, the warehouse as a guest. “Managed” was its complement, data the warehouse ingested into its own storage and formats, fully owned, fully optimized, deletable with the table. The pair encoded one axis, is the data inside the platform or outside it, and the axis made sense when platforms were monoliths.

Iceberg dissolved the monolith’s boundary and kept the words. Now the data is always “outside” in the old sense, open files in object storage, and always potentially “inside” in a new sense, governed by some catalog, maintained by some service, created through some platform’s path. Each platform re-drew the managed-external line along whichever unbundled seam mattered most to its architecture: some along storage provisioning, the platform’s buckets versus yours, some along catalog authority, tables the platform’s catalog owns versus tables it merely federates to, some along maintenance, tables the platform optimizes versus tables it leaves alone, and some along lifecycle, tables whose DROP deletes data versus tables whose DROP removes a registration. Add the federation era’s coinages, foreign catalogs, linked tables, mirrored tables, external catalogs that are internal to someone else, and the vocabulary became a set of homonyms wearing a shared costume.

The practical consequence shows up in exactly three places, worth naming so you recognize the genre. Design reviews, like the one this article opened with, where a decision stalls on an ambiguous word. Vendor evaluations, where “supports external tables” and “supports managed Iceberg” are claims whose content varies by claimant, and the compatibility conversations this site has covered, where the same engine’s same write succeeds against one platform’s namespace and is refused by another’s, both behaving correctly, per policies the words were supposed to summarize and did not. The cure in every case is the same move: stop translating between vendor vocabularies directly, and translate each into a common structure instead. Here is the structure.

The homonym problem, demonstrated in one sentence pair before the structure arrives, because seeing it cures more than describing it. “We recommend managed tables for production workloads” means, from a warehouse-genre vendor, “let us hold the storage, run the maintenance, and own the lifecycle,” and means, from a catalog-genre vendor, “make this catalog the commit authority rather than merely registering an external table,” and both sentences are good advice inside their own vocabularies while recommending nearly disjoint architectures. A team that reads the second sentence with the first sentence’s dictionary concludes, wrongly, that production readiness requires surrendering storage, and a team reading the first with the second’s dictionary concludes, also wrongly, that a commit-authority decision settled the maintenance question. Neither vendor misled anyone. The dictionary did.

Ownership, Decomposed: Five Questions That Actually Have Answers

Ask these five questions about any Iceberg table, and its ownership is fully specified, whatever anyone’s documentation calls it. The questions are deliberately answerable, each one resolves to a name, a team, a service, an account, and deliberately independent, because their independence is the fact the old vocabulary denied: any combination of answers is a coherent posture, and real estates run most of the combinations somewhere.

Question one: who is the commit authority? Every Iceberg table has exactly one place where its current-metadata pointer advances atomically, and whoever operates that place, a self-hosted Polaris, a vendor’s catalog service, a cloud catalog’s REST interface, holds the table’s transactional soul. Commit authority is the least ambiguous dimension, it cannot be shared, forked authority is corruption, and it is the dimension the REST era has clarified most, since the protocol makes the authority an explicit service every writer names.

Question two: who owns the storage? The bucket where the files live has an account, a payer, an access policy root, and a deletion switch, and that owner is a distinct fact from the commit authority. Platform-provisioned storage, the vendor’s bucket under the vendor’s account, and customer-provisioned storage, your bucket that a catalog is configured against, differ in cost attribution, in who can reach the bytes outside the catalog’s mediation, and in what happens to data when commercial relationships end. Most of what the old “managed versus external” axis measured lives in this question alone, which is why the old words fail: they answer one question of five.

Question three: who runs maintenance? Compaction, snapshot expiration, orphan cleanup, and, as this site has covered at length, the v3-era additions, shred-aware rewrites, lineage-preserving compaction. Somebody runs these, a platform’s automatic optimization service, your scheduled jobs, or, in the failure mode, nobody, and the runner needs write access, a schedule, and accountability for the table’s physical health. Maintenance ownership is the dimension most often left implicit, and the one whose vacancy produces the slowest-burning incidents.

Question four: who controls lifecycle? What does DROP TABLE do, remove a registration or delete data, who can do it, and who owns retention, the snapshot-expiration policy that, as the row-lineage discussion showed, is now part of downstream contracts rather than mere cost hygiene. Lifecycle authority also covers the quieter rights: renaming, relocating, changing format versions, the operations that alter what the table is rather than what it contains.

Question five: where does policy bind? Table grants, row and column controls, audit logging, the governance surface. In the engine era, policy lived in each engine, inconsistently, and the scan-planning era gives it a home in the catalog, enforced at planning time for every conforming client, which makes “whose policy engine governs reads of this table” a precise question with, ideally, one answer, and, in federated realities, sometimes several partial ones worth mapping.

Lay the five out as a card and every table in your estate gets a row:

The card’s power is that vendor vocabulary compresses into it losslessly in one direction: any platform’s “managed table” is some specific pattern of five answers, discoverable from its documentation in ten minutes, and two platforms’ patterns can be compared cell by cell even when their words collide. The reverse direction, recovering the five answers from the word alone, is exactly what does not work, which is the entire confusion in one sentence.

The Vocabulary Map: Translating What Vendors Say

With the card in hand, tour the vocabulary as genres rather than as brand-by-brand claims, because the genres are stable while individual platforms’ details shift release by release, and because the method, translate the word into five answers, matters more than any single translation.

The warehouse-genre “managed Iceberg table” typically compresses: platform commit authority through its catalog interface, platform-provisioned or platform-controlled storage, platform-run maintenance, platform lifecycle where DROP deletes data, and platform policy. It is the old managed table rebuilt on open format, everything owned, with the openness expressed as external engines being able to reach in through the catalog’s REST interface, reads broadly, writes as policy allows. The same genre’s “external” or “externally managed” table flips commit authority outward, the table lives in someone else’s catalog, the platform connects as a client, and with that flip, maintenance, lifecycle, and usually policy follow the authority out, the platform holding at most a read-oriented governance overlay.

The catalog-genre vocabulary, the Polaris lineage prominently, drew its line inside the catalog itself, and its word pair is worth learning precisely because it names the REST era’s key distinction. An “internal” or catalog-managed table is one the catalog is the commit authority for, created through it, committed through it, governed by it, with storage typically customer-provisioned and maintenance explicitly the operator’s design decision. An “external” table, in this genre, is one the catalog represents but does not command, registered for discovery and federated read, its commit authority elsewhere, and the genre is explicit in the way the warehouse genre is not that this is a per-table fact inside one catalog, not a property of the platform relationship. When a catalog-genre platform says “managed,” it is speaking about dimension one, and mostly letting dimensions two and three float free, which is exactly the opposite compression from the warehouse genre, and the collision of those two compressions is, in my experience, the single most common source of the design-review argument this article opened with.

The federation-genre coinages, foreign catalogs, linked or mirrored tables, catalog integrations, describe reach across authorities: platform A’s users querying tables whose commit authority is platform B. The five-dimension reading keeps these honest. A federated table’s commit authority, storage, maintenance, and lifecycle all belong to the far side, whatever the near side’s interface implies, and the near side contributes, at most, a policy overlay on its own users’ access plus a synchronized registration whose freshness is an operational detail worth asking about. Mirroring adds a copy with its own card, two tables, two ownership rows, and a synchronization arrow, which sounds obvious and prevents real incidents, because a mirror whose consumers believe they are reading the original have expectations about freshness and writability that a filled-out card corrects in advance.

And the automation-genre vocabulary, tables that platforms create from streams or convert from other formats, “streaming tables,” “converted tables,” compresses a temporal claim: the platform holds authority now because it is producing the table, and the interesting questions are the steady-state card once production stabilizes, plus one this genre adds, who owns the table if the automation is turned off.

The method, restated as the takeaway: when documentation says managed, external, foreign, linked, internal, or any future coinage, write the five answers in the margin, and argue about those. Vocabulary is marketing surface, the card is load-bearing structure, and the ten minutes of translation is the cheapest de-confusion available in platform selection.

One translation performed in full, to make the method concrete. Documentation sentence: “External tables let you query Iceberg data managed by an external catalog directly from our platform, with unified governance.” The margin work: commit authority, external, the other catalog’s, that part is plain. Storage, follows the authority, theirs or their customer’s, ask which. Maintenance, unstated, meaning theirs, and worth confirming, because “query directly” says nothing about who compacts. Lifecycle, theirs, and now interrogate “unified governance,” because it is doing dimension-five work: does it mean this platform’s grants govern its own users’ access to the federation, an overlay, or does it claim planning-time enforcement of the far catalog’s policies, a much stronger and rarer thing? The sentence read smoothly and answered one dimension of five, the margin work surfaced three questions for the vendor call, and that ratio, one answer, three surfaced questions per polished sentence, is roughly what the method yields everywhere it is applied, which is the argument for applying it everywhere.

Ownership in the REST Catalog Era

The REST protocol did not just standardize an API, it redistributed the ownership dimensions, and reading the redistribution explains why the vocabulary is shifting under everyone’s feet.

Commit authority became explicit and portable. Before the protocol, authority hid inside whichever metastore an engine was configured against, and moving it meant re-plumbing every engine. With the protocol, authority is a URI every client names, tables carry their authority as configuration rather than as embedded assumptions, and the market for authority opened, self-hosted open-source catalogs, managed open-source derivatives, vendor services speaking the same interface, all substitutable in principle, all competing on the operational qualities around the same commit semantics. The unbundling that created the vocabulary problem also created the standard that resolves its most important dimension: whoever answers the commit endpoint owns dimension one, no interpretation required.

Storage relationships got mediated by credential vending. The catalog handing scoped, expiring storage credentials to authorized clients, per table, per operation, changed dimension two’s texture: customer-provisioned storage no longer means every engine holds bucket keys, it means the catalog is the storage relationship’s broker, and platform-provisioned storage no longer means opacity, since vended credentials let external engines reach the platform’s buckets under the platform’s rules. Vending moves the practical center of storage governance into the catalog without moving the bucket, which is why “whose bucket” and “who controls access to the bucket” are now separable answers on the card, and both worth writing down.

Policy found its enforcement point in scan planning. This site has covered remote scan planning’s governance consequences in depth, and the ownership reading is compact: when clients ask the catalog to plan, the catalog’s policy binds at the only chokepoint every conforming reader passes, and dimension five collapses from “each engine’s best effort” toward “the authority’s single answer.” The composite that results, authority plus vending plus planning, is a coherent ownership bundle the old vocabulary has no word for: the catalog owns the table’s transactional, access, and governance surfaces while owning neither the storage nor the compute, and the industry’s current terminological churn is, at bottom, everyone inventing names for that bundle.

Maintenance is the dimension the protocol left untouched, and its silence is meaningful. Nothing in the REST interface says who compacts, and the market is answering instead: catalogs growing optimization services, platforms bundling automatic maintenance as the paid tier’s substance, operators keeping scheduled jobs. On the card, dimension three remains the one you must ask about explicitly, because no protocol answer exists to infer it from, and the v3-era obligations, shred-aware, lineage-preserving rewrites, have raised the cost of getting the answer wrong.

The library era stresses the card from a new direction, worth a forward-looking paragraph. When writers multiply beyond engines, services embedding table libraries, agents committing through tool calls, the population this site’s library-era coverage describes, the ownership answers do not change, one authority, one policy surface, and the load on them does: dimension five’s grant model must now express service and agent principals, not just human roles, dimension one’s authority becomes the audit chokepoint for autonomous writes, exactly where you want it, and dimension three inherits the tiny-commit hygiene questions that many small writers raise. The five-dimension card was built for a world of a few big engines and turns out to be exactly the right instrument for a world of many small principals, which is the kind of durability that suggests the decomposition is carving reality at a joint.

The Decision Framework: Which Posture for Which Tables

Ownership is chosen, table class by table class, and here is the framework I use, organized around the question that actually decides each dimension. Two ground rules before the dimensions: postures are per table class, not per organization, because the events table and the derived dashboard table deserve different cards, and postures are revisited on role changes, because the experiment that became the system of record has outgrown the card it was created with, usually without anyone re-filling it.

For commit authority, the deciding question is blast radius versus coherence. One authority for everything maximizes coherence, one policy surface, one audit stream, one operational relationship, and concentrates risk, one outage gating every write, one vendor negotiation holding every table. Most organizations land on few authorities with deliberate boundaries: a primary catalog for the shared estate, where coherence pays daily, and separate authorities only where a boundary genuinely exists, a regulated enclave, an acquisition mid-integration, a product team shipping tables as a product. The anti-pattern is authorities by accident, one per tool that happened to create tables, which is how estates end up with five partial catalogs and no answer to “what tables do we have.”

For storage, the deciding question is who must survive whom. Customer-provisioned storage means the data outlives any platform relationship, bytes in your account, readable by the next catalog you point at them, and it carries the operational duties, encryption posture, lifecycle rules, cost management. Platform-provisioned storage trades those duties for a dependency whose exit cost is a data migration. The framework’s blunt version: tables you consider organizational assets belong in storage you control, tables that are operational exhaust of a platform, its logs, its internal state, can live wherever the platform prefers, and the gray middle, derived tables a platform produces from your data, deserves the explicit conversation it rarely gets.

For maintenance, the deciding question is fleet scale versus table criticality. Automatic platform maintenance wins on fleets, hundreds of tables kept healthy without a roster, and its policies are generic by construction. Owned maintenance wins on the tables where this site’s operational guidance applies with force, the high-cadence streaming tables, the CDC mirrors with delete-resolution contracts, the v3 tables whose compaction must preserve shredding and lineage, because those tables need policies tuned to their workloads and verified after every tooling change. Run both, deliberately: platform automation as the fleet baseline, owned regimes for the named critical tables, and zero tables in the vacancy between.

For lifecycle, the deciding question is who answers to the retention requirement. Whoever owns the compliance obligation, legal hold, deletion rights, the changelog-consumer contracts retention now encodes, should hold the lifecycle switches or a documented delegation of them, and DROP semantics should be verified per platform rather than assumed, because registration-removal versus data-deletion is precisely the kind of difference that surfaces during an incident.

And for policy, the deciding question is where your enforcement can actually reach. Policy at the commit authority binds everything that speaks the protocol properly, which is the strongest available position and argues for concentrating grants there, with engine-side controls as defense in depth rather than as the system of record. Federated tables constrain you honestly: the far authority’s policy governs, your overlay governs your users, and pretending otherwise is dimension-five wishfulness.

Three Tables, Three Cards

The framework lands better filled in, so here are three archetype tables with their cards completed, each a posture chosen on purpose.

The streaming events table, the platform team’s own. Commit authority: the organization’s self-hosted or managed open-source catalog, because this table is shared estate, written by a stream, read by six engines, and coherence at the center pays daily. Storage: customer-provisioned, the organization’s bucket, because three years of clickstream is an organizational asset that must outlive any platform decision. Maintenance: owned, a tuned regime, because this is exactly the high-cadence table whose compaction cadence, expiration policy, and lineage-preserving rewrites this site’s operational articles were written about, and generic automation is not enough. Lifecycle: platform team holds it, DROP verified as registration-plus-optional-delete, retention sized to the slowest changelog consumer. Policy: at the catalog, planning-time enforced, engine-side controls demoted to defense in depth. Total posture: authority and governance centralized, storage sovereign, maintenance purpose-built, and every cell chosen because this table is infrastructure.

The finance BI table, fully bundled on a warehouse-genre platform. Commit authority: the platform’s catalog, because every producer and consumer of this table lives inside that platform and the coherence question is trivial. Storage: platform-provisioned, accepted deliberately, because this table is derived nightly from sovereign upstream tables, and its exit story is “rebuild from upstream,” not “migrate the bytes.” Maintenance: platform automatic, correct for a modestly sized, batch-written table. Lifecycle: the platform’s, with the one-hour sandbox DROP verification done and filed. Policy: the platform’s grants, which the finance team already administers. Total posture: maximally bundled, and sound, because the card was filled against the table’s actual role, replaceable derived output, rather than against a purity principle. The bundling that is a trap for the events table is a convenience here, and the card is what tells the two situations apart.

The partner-federated reference table. Commit authority: the partner’s catalog, full stop, and everything follows from writing that cell honestly. Storage: theirs. Maintenance: theirs, with their compaction cadence a fact you can ask about and cannot set. Lifecycle: theirs, meaning the table can change shape or vanish on their schedule, which is why the consuming pipeline was built with schema-drift alarms. Policy: their grants govern the table, your overlay governs which of your users see the federation, and the mirror the analytics team requested for latency gets its own card, marked as a copy, with the synchronization lag published beside it. Total posture: a consumer’s card, and the discipline of filling it is what keeps consumption from quietly hardening into dependency nobody priced.

Three tables, fifteen cells, no vocabulary required, and the exercise generalizes: an estate’s important tables fit on one spreadsheet, and the arguments that used to orbit words become row-by-row comparisons with answers. The cards also compose upward into the estate view leadership actually needs, what fraction of critical tables sit in sovereign storage, how many maintenance vacancies exist, where the single points of vendor concentration are, questions that a vocabulary-based inventory cannot answer and a card-based one answers with a pivot table.

What Ownership Costs at Exit

Every posture is also a future migration, so price the exits while choosing, because exit cost is where ownership stops being abstract.

Commit authority is the cheapest dimension to move, by design of the protocol era. Migrating tables between REST catalogs is metadata registration plus client reconfiguration, no data movement, and the ecosystem’s direction, catalog-to-catalog federation, migration tooling, makes the path smoother each year. The cost concentrates in the surround: policies re-expressed in the new authority’s model, audit continuity, credential-vending re-plumbing, service accounts everywhere. Annoying, bounded, done in a quarter.

Storage is the expensive dimension, today, in one specific way. Moving buckets means moving bytes, which is priced by egress and time, and, in the current format, it also means the metadata rewrite this site’s proportionality coverage flagged as the purest disproportionality on the books: absolute paths embedded throughout the tree, so relocation rewrites the metadata even though nothing semantic changed. The v4 relative-paths work converts that rewrite into a catalog-side pointer change, spec text already moving, and until it lands, storage choices carry the full weight: platform-provisioned storage plus embedded absolute paths is the deepest lock-in composite in the lakehouse, and worth entering only with eyes open.

Maintenance exits are cheap and sneaky. Turning off a platform’s automatic optimization is a decision, standing up the replacement regime is a project, and the gap between the two is where tables quietly degrade, which argues for sequencing every platform exit as replacement-first, verification, then cutover, with the four health metrics this site prescribes watched across the boundary.

Lifecycle and policy exits are re-expression problems, grants, retention rules, and holds translated between governance models that never map one to one, and their cost scales with how much policy you accumulated, which is an argument for policy hygiene all along, fewer, clearer rules exit better than archaeological layers.

The composite lesson: exits are priced per dimension, the dimensions move independently, and the resilient posture is the one where no single vendor holds all five for the tables that matter. That is not a purity rule, plenty of tables deserve a fully bundled posture for its convenience, it is a portfolio rule about the estate’s center of gravity.

Gravity itself deserves the final word on exits, because dimension two’s pull operates on the other four. Data attracts compute, compute attracts tooling, tooling accretes policy and process, and an estate whose bytes sit in one platform’s storage drifts, over years, toward that platform holding the other dimensions too, not through any decision but through a thousand conveniences. The counterweight is equally structural: sovereign storage plus a protocol-standard commit authority makes the other dimensions genuinely contestable, vendors competing to run your maintenance and host your policy against tables neither of you has to move. The ownership question, asked at estate scale over a decade, is really the question of which gravitational configuration you built, and the card, filled per table, is how the configuration gets built on purpose.

Failure Modes: When Two Systems Both Think They Own It

The card’s dimensions also index the characteristic incidents, each one an ownership ambiguity cashing out.

Split-brain authority is the severe one: a table registered in two catalogs, both accepting commits, histories forked, and the fork is corruption, not inconvenience. It arises from migration processes that never decommissioned the old registration, and from federation configured as dual authority instead of authority-plus-reference. The damage pattern is worth recognizing early: each catalog’s readers see a self-consistent table missing the other line’s commits, no error anywhere, complaints arriving as “my write disappeared” from whichever side lost a given race to write metadata, and by discovery time the two histories share an ancestor and diverge, with reconciliation a manual merge of whichever side’s changes can be replayed. The prevention is procedural monogamy: one commit authority per table, ever, enforced by making every second registration explicitly read-only or explicitly a mirror, and the audit below exists largely to catch violations before the divergence does.

Vacant maintenance is the slow one, covered throughout this site and restated here as an ownership fact: the platform assumed you were compacting, you assumed the platform was, and the table’s metadata told the truth about the vacancy for months before latency did. Every table’s card gets a named answer for dimension three, “automatic” counts, “unknown” does not.

Assumed policy is the embarrassing one: controls configured in an engine that some other engine never enforced, row filters that governed dashboards while notebook users read the files directly, the pre-planning-era governance gap this site has described, persisting wherever direct file access persists. The fix is architectural honesty on dimension five: policy binds where enforcement reaches, vended credentials and planning-time enforcement extend the reach, and paths outside the reach are named, either closed or accepted in writing.

Lifecycle surprise is the one that pages legal: the DROP that deleted data someone believed was a registration removal, or its inverse, the “deleted” table whose bytes persisted in a bucket past a deletion obligation. Both are dimension-four verification failures, both are prevented by testing DROP semantics per platform in a sandbox, which takes an hour and is, per hour, the best risk reduction in this article.

And mirror drift is the quiet one: consumers reading a mirrored table as if it were the source, freshness assumptions unexamined, until a decision gets made on stale data. Mirrors get cards too, with the synchronization arrow and its lag as first-class facts.

The Shared-Table Special Case: Ownership Is Not Access

One clarification prevents a whole category of confusion, so it gets its own section: a table with many engines is not a table with many owners.

The multi-engine table, Spark writing, DuckDB probing, a BI platform reading, a partner federating in, is the lakehouse’s whole premise, and every one of those participants is a client of the same five-dimension card, not a claimant on it. The commit authority is one catalog regardless of how many engines commit through it, the concurrency machinery this site has covered arbitrating their races under the one authority’s roof. Policy is one surface with many principals. Maintenance is one regime whose obligations, lineage preservation, shred awareness, bind whichever tool performs it. Access multiplies, ownership does not, and the sentence to deploy in the design review is exactly that one.

The confusion arises because access differences masquerade as ownership differences. When one platform’s engines can write a table and another’s are refused, the practitioner’s instinct says “their table,” and the card says otherwise: same owner, different grants, dimension five doing its job. The compatibility work this site has published, probing which operations each catalog permits each engine, is, in ownership terms, the empirical mapping of one authority’s policy surface, and reading refusals as policy rather than as ownership keeps the mental model right where the incidents are wrong. The inverse confusion matters too: an engine having storage credentials that bypass the catalog does not make it an owner, it makes it a governance hole, dimension five’s reach failing short of dimension two, the assumed-policy failure mode wearing a different hat.

Where genuine multi-party ownership is wanted, joint ventures, data products with contractual co-management, the card handles it by decomposition rather than by inventing shared authority: one party holds commit authority, the contract assigns other dimensions explicitly, maintenance to whoever runs it, lifecycle rights spelled out, and the arrangement is documented as five assignments rather than as an ambiguous “jointly managed,” because the format has no notion of joint commit authority and the contract should not pretend otherwise. Data-sharing arrangements land in the same frame from the other side: sharing is granting access, ownership unchanged, and the recipient’s card for the shared table is the federated archetype’s, filled honestly, which is the paperwork that keeps sharing from being mistaken for transfer on either side of the agreement.

The Ownership Audit

The article operationalized, as an afternoon’s exercise per domain.

Inventory the authorities: list every catalog-like thing that can accept a commit, including the legacy metastores and the tool-embedded catalogs nobody counts, and for each table in scope, record which one is its authority. Every table with two answers is a split-brain candidate to resolve this week. Every table with zero answers is unmanaged risk wearing a bucket path, and estates that have never run this inventory reliably find a few of each, which is precisely why the inventory comes first.

Fill the cards: for the tables that matter, the five answers, from documentation and configuration rather than from memory, with dimension three’s answer verified against actual job schedules and dimension four’s verified in a sandbox. The card template fits in a spreadsheet row, and the estate’s ownership posture becomes a filterable table, which is the point.

Price two exits: pick the most-bundled critical table and the most-federated one, and write the one-page exit sketch for each, per dimension, using the costs above. The sketches date quickly and the exercise does not, because it converts ownership from vibes into numbers once, after which updates are cheap.

And schedule the re-run: quarterly for the inventory, annually for the cards, triggered re-runs on platform migrations and vendor renegotiations, which are exactly the moments the cards are consulted and exactly the moments stale cards mislead.

Two refinements sharpen the audit at low cost. Verify dimension five’s reach empirically rather than from grant screens: pick one governed table, attempt access through each path a determined user has, the SQL interface, the notebook with storage credentials, the export tool, and record which paths the policy actually stopped, because the assumed-policy failure mode hides precisely in the gap between the grants configured and the paths enforced, and one hour of adversarial self-testing maps the gap. And for every card whose dimension-three answer is “platform automatic,” capture what the automation actually does, which operations, what cadence, which v3 obligations it honors, from documentation or support, because “automatic” spans everything from a full maintenance regime to a compaction-only sweep that never expires a snapshot, and the word alone is another homonym wearing a reassuring costume.

Where the Vocabulary Goes Next

Prediction, briefly, because the trajectory is visible. The five dimensions are stabilizing into the industry’s real ontology even as the words lag: credential vending and planning-time enforcement are making the catalog-owned bundle the default center, maintenance is professionalizing into services with contracts rather than assumptions, and relative paths will demote storage location from destiny to detail. The words will catch up the way words do, unevenly, vendor by vendor, and the practitioners who think in dimensions will translate each new coinage on arrival, the skill this article was actually teaching.

Two vocabulary bets, dated for accountability. First, “commit authority” or a close synonym enters mainstream documentation within a couple of years, because the REST era made the concept precise and precise concepts eventually get names, and once it lands, the managed-external pair will quietly retreat to describing storage, its original job, ending the homonym era through specialization rather than reform. Second, maintenance gets its contractual vocabulary next, service levels for compaction cadence and v3-obligation compliance the way uptime got its nines, because the vacancy failure mode is common enough and expensive enough that “who maintains this table” is becoming a procurement question, and procurement questions grow contract language. “Managed” and “external” will keep meaning five different things in five different documents through the transition, and it will matter less each quarter, because the people making the decisions will have stopped arguing about words and started comparing cards.

Conclusion

Who owns an Iceberg table is five questions, not one word: who commits, whose bucket, who maintains, who holds the lifecycle switches, and whose policy binds. The old vocabulary compresses those five lossily and differently per vendor, the REST era made the first question precise while redistributing the rest, and every recurring incident in this territory, forked histories, vacant maintenance, assumed policy, surprise deletions, is an ambiguity in one nameable dimension. Decompose the word, fill the card, choose each dimension deliberately per table class, price the exits while choosing, and the managed-versus-external argument dissolves into what it always should have been: a short list of factual answers, compared cell by cell, owned on purpose. The two architects from the opening, handed the card, settle their argument in ten minutes, because it turns out one was right about dimension two and the other about dimension one, and the table they were designing needed both answers written down, which is, in one sentence, what this article believes about the whole vocabulary.

Keep Going

If this piece was useful, I have written a lot more on Apache Iceberg and lakehouse architecture. Apache Iceberg: The Definitive Guide and Apache Polaris: The Definitive Guide, which I co-authored for O’Reilly, cover catalogs, governance, and the architecture decisions behind every dimension in this article. You can find every book I have written, across lakehouse architecture, Apache Iceberg, Apache Polaris, and AI, at books.alexmerced.com.