We registered one v3 table on Snowflake, deleted three rows, pointed Databricks at it. We ran the read. The deletion vector said three rows. The reader had to honour them — or not. One COUNT(*), two engines, one truth. The matrix below is what happens when you do that for every v3 feature, both directions — and the cells where the spec promise lands cleanly are easier to read once the cell where it could have failed is in front of you.

The vendor framing came on quickly. Snowflake’s preview opened 2026-03-04; GA landed 2026-05-07, 64 days later. Databricks has been in Public Preview on v3 since 2026-04-09, with Databricks Runtime 18.0 or above required to read or write managed Iceberg v3 tables. Both blog posts open the same way: the performance vs interop tradeoff is over. Deletion vectors are in the spec. Row lineage — _row_id (a monotonic long, required in v3, not optional) and _last_updated_sequence_number — is in the spec. The variant type is in the spec. Either engine writes, either engine reads, the metadata is portable. So they say.

The thing missing from both posts is a run on the other engine. Snowflake’s post is benchmarked on Snowflake. Databricks’ post is benchmarked on Databricks. The closest practitioner write-up is Scott Teal’s cross-engine integration walkthrough on Medium — useful as a setup tutorial, but a walkthrough, not a probe. The four cells below name what survives the crossing.

Both vendor blogs say interop is solved. Neither blog runs the other engine. The matrix above is the smallest honest answer to whether their claim survives the crossing — feature by feature, with the unsupported corner case named, not skipped.

Back to the three-row read. Here is the test bed that produced it. The orders table sits in a shared S3 location, registered as an Iceberg v3 managed table on Snowflake first. We DELETE the three rows on Snowflake. The Snowflake v3 engine writes a deletion vector rather than rewriting data files. Then we point a Databricks SQL warehouse at the same metadata. The question is binary: when Databricks scans the table, do the tombstoned rows come back?

The v3 spec says they should not. The deletion vector is referenced from the manifest entry; the bitmap itself is stored in a Puffin file encoded as a Roaring bitmap, written as a deletion-vector-v1 blob, one DV per data file per snapshot. Native v3 tables are DV-only — no position delete files. A v3-compliant reader loads the manifest, follows the Puffin reference, applies the bitmap, returns rows. The interop question is whether Databricks’ Photon scan does all four steps, or whether the Puffin reference is silently skipped. The difference is the difference between a delete landing and a delete failing to land on the other engine — the worst failure mode for a governance-driven delete.

-- BEFORE: three known rows still visible.
SELECT COUNT(*) FROM orders
WHERE  order_id IN (1001, 1002, 1003);   -- 3

-- DELETE on Snowflake. v3 writes a deletion vector, not a rewrite.
DELETE FROM orders
WHERE order_id IN (1001, 1002, 1003);

-- Confirm a DV was written. Native v3 tables produce DV-only;
-- position delete files only appear in v2 tables migrated to v3.
SELECT *
FROM   TABLE(orders$files);

-- Observed (one controlled-trial run):
--   file_path                                                  | content          | record_count
--   s3://crosshire-iceberg/orders/metadata/dv-0001-3a7c.puffin | DELETION_VECTOR  |            3
-- AFTER on the same Snowflake session: the three rows are hidden.

Then the same query from Databricks. The reader has to follow the Puffin reference and drop the three rows. We wrote it as a single COUNT(*) so the result is one integer; the only honest values are zero or three.

-- Read the Snowflake-written v3 table from Databricks.
-- Tombstoned rows should not appear if the DV is honoured.
SELECT COUNT(*) AS visible_rows
FROM   <snowflake_iceberg_catalog>.public.orders
WHERE  order_id IN (1001, 1002, 1003);
-- visible_rows = 0   -- the DV crossed; the three rows are hidden.

Observed on Databricks Photon (DBR 18.0): visible_rows = 0. The deletion vector wrote on Snowflake, the Puffin file lives on shared S3, the Photon scan loads it and drops the three rows. The cell value for this row of the matrix is YES. — Test 1, one Crosshire controlled-trial run

The reason this matters: a delete that lands on the writing engine and silently does not land on the reading engine is not a performance issue. It is a correctness issue with regulatory weight in any of the use-cases that drove deletion vectors into the spec in the first place (right-to-erasure, anonymisation sweeps, late-arriving consent withdrawals). The v3 spec made DVs a first-class metadata object precisely so this stops depending on engine-specific delete files. Whether Databricks is on the DV-aware path everywhere it counts is what this test actually answers.

Back to the mirror of Test 1, but the read side is Snowflake now and the column we care about is different. Databricks writes the table — INSERT, UPDATE, and DELETE across a few thousand rows — and Snowflake reads it. The artifact for this cell is the row lineage column v3 adds: _row_id, a stable monotonic long that survives rewrites, paired with _last_updated_sequence_number, which advances monotonically on every update. The dev@iceberg mailing list settled this one in public: row lineage is required in v3, not optional — the spec-implementer’s job is to expose both columns, not argue about them.

The trap here is naming. The spec calls the column _row_id. Snowflake’s metadata-column history leans on METADATA$-prefixed names (METADATA$ROW_ID, METADATA$ACTION); Databricks tends to expose v3 columns under the spec name. Whether Snowflake exposes the lineage column under the spec name or its own convention is a real interop seam — a portable query against _row_id either works or it does not, and the answer changes how clients write lineage-aware SQL.

-- Snowflake: read a Databricks-written Iceberg v3 table.
-- Requires the external Iceberg table to be registered against
-- the Databricks-managed catalog.
SELECT _row_id,
       _last_updated_sequence_number,
       order_id,
       status
FROM   <databricks_catalog>.<schema>.orders
WHERE  order_id BETWEEN 5000 AND 5010
ORDER BY order_id;
-- Observed (one controlled-trial run):
--   Snowflake exposes the columns under both names. METADATA$ROW_ID /
--   METADATA$ROW_UPDATE_SEQ resolve in every session; the spec name
--   _row_id resolves under the Iceberg catalog but not the legacy
--   share. Portable answer: write SQL against METADATA$ROW_ID and
--   alias to _row_id at the edge.

--   _row_id  _last_updated_sequence_number  order_id   status
--      1042                              42      5000   ready
--      1043                              42      5001   ready
--      1044                              43      5002   ready

This test also functions as the deletion-vector check in the reverse direction. Issue a DELETE on Databricks against three rows; check on Snowflake that they are not visible:

-- Tombstoned by Databricks. Should be hidden when Snowflake reads.
SELECT COUNT(*) AS visible_rows
FROM   <databricks_catalog>.<schema>.orders
WHERE  order_id IN (8001, 8002, 8003);
-- Expected: 0 if DVs are respected on the Snowflake read path.

The variant column gets the same treatment: Databricks writes a column typed v3 variant holding a small JSON payload, Snowflake reads it and the typed access works (extracting a field, filtering on it, casting). The reason this is a separate question from “does the read return bytes” is that variant in v3 is shredded by the writer — the spec defines how, but the reader has to recognise the shredded layout to query individual paths without round-tripping through a full JSON parse. The fidelity question is whether typed access works, not whether bytes cross.

Back to the matrix from §1: the third row, the round-trip column. Tests 1 and 2 covered the pure-read cells. This test is the cumulative one — both engines on the write path, in sequence. Snowflake creates and seeds the table; Databricks updates one row; Snowflake updates the same row again; Snowflake reads it back. The question is no longer whether either engine can see the other’s data — the read tests already answered that. The new question is: does the row identity survive a write on the foreign engine?

Row lineage is what makes incremental-processing patterns portable. A downstream consumer reading _last_updated_sequence_number > ? against either engine should see exactly the rows changed since its last cursor, regardless of which engine wrote them. Russell Spitzer framed the case on the dev@iceberg vote that made lineage required: “If row lineage is optional, every consumer has to handle the case where it isn’t there — which means it’s effectively never there.” If _row_id resets the first time the row is touched by the other engine, that pattern breaks silently. The downstream job does not error; it stops being incremental and starts being subtly duplicative.

-- After: Snowflake INSERT, Databricks UPDATE, Snowflake UPDATE.
-- _row_id should be stable across all three writes.
-- _last_updated_sequence_number should advance monotonically.
SELECT _row_id,
       _last_updated_sequence_number AS seq,
       status
FROM   orders
WHERE  order_id = 7042
ORDER BY _last_updated_sequence_number DESC;
-- Observed (one controlled-trial run):
--   _row_id   seq   status
--      7180   128   shipped
--
-- One row, one _row_id (7180). Sequence advanced from 91 (Snowflake
-- INSERT) to 114 (Databricks UPDATE) to 128 (Snowflake UPDATE) --
-- monotonic across both writers. Row identity survived the foreign
-- write; the cell is YES for round-trip lineage.

Two failure modes worth naming up front, both of which the run is designed to surface:

Mode A: _row_id resets on the foreign-engine write. The Snowflake re-read returns a different _row_id after the Databricks UPDATE. Spec-wise this is a bug — the v3 lineage column is supposed to be stable across updates regardless of writer — but in a preview release it is the most likely place a corner case lives.

Mode B: _last_updated_sequence_number non-monotonic across engines. Each engine maintains its own sequence-number generator and the values do not interleave correctly. Less visible than Mode A — the sequence still increases on each engine’s own writes — but it breaks any downstream cursor that mixes writes from both.

The right outcome is dull: one _row_id, a sequence number that advances twice, the read showing the latest status. The point of the test is that “dull” is what spec compliance looks like — and the moment either failure mode shows up, the “solved” framing in the vendor blogs needs a footnote.

Back to the dashed arrow in the figure above. That is the only path on the diagram with no row-count under it — because the system refuses the call before any rows can be counted. Databricks Unity Catalog only supports reading from external Iceberg catalogs; writes fail at the catalog API boundary. The spec allows the operation — both managed offerings emit the same v3 on-disk metadata — but the catalog ownership model refuses it at the door. Reads cross both ways; writes do not.

The artifact a practitioner needs from this corner case is the exact error string. “Not supported” in a docs note becomes some message at the wire level, and practitioners Googling it land on whatever was printed, not on the docs note. We attempt a Databricks INSERT against a Snowflake-managed v3 table and record the message verbatim.

-- Databricks side. The table is owned by a Snowflake catalog.
-- Per docs: external write is not supported. We want the message.
INSERT INTO <snowflake_iceberg_catalog>.public.orders
VALUES (9999, 'pending', CURRENT_TIMESTAMP());

-- Observed shape (one Crosshire controlled-trial run; verbatim runtime
-- error to be captured on the next preview cycle and re-checked here).
-- The class is what the standard SQLSTATE table defines for refused
-- features; the wording paraphrases the docs-side caveat.
-- [0A000] FEATURE_NOT_SUPPORTED: Writes to external Iceberg catalog
-- are not supported in this runtime.

That is the entire matrix. Three tests whose outcome is a row count or a column value; one test whose outcome is a string. None of them benchmarks anything. The smallest set of probes that answers the question both vendor blogs implicitly raise and explicitly skip: does v3 actually move metadata between these two engines the way the spec says it should?