Generic Tables

Time: ~7 minutes. Tangible win: explain what a Generic Table is, why Polaris added a table type that isn't Iceberg, and what capabilities you deliberately give up by using one.

Reading-only lesson Everything so far assumed "table in Polaris" means "Iceberg table with Polaris-managed commits and credential vending." Generic Tables are Polaris's answer to "I have Delta/CSV/other-format tables I still want cataloged in the same namespace." This is a beta feature with no bundled local exercise, so treat this lesson as a close reading rather than a script — the same pattern Lesson 9 (Flight SQL) used in the Arrow course.

A Generic Table is a Polaris entity that records just enough to identify a non-Iceberg table: name, format (e.g. delta, csv), an optional base location, and free-form properties. There is deliberately no schema or partition spec stored — Polaris isn't trying to understand Delta's or CSV's internal structure.
The tradeoff for that simplicity: Generic Tables get none of Iceberg tables' Polaris-side machinery — no commit coordination (concurrent-write conflict handling) and no credential vending (Polaris handing out short-lived, scoped storage credentials per request). "It is the responsibility of the engine to coordinate loading and committing data," per the Polaris docs — Polaris is a directory entry here, not an active participant in writes.
Generic Tables and Iceberg tables are not interchangeable through each other's APIs — you can't load or drop a Generic Table via the Iceberg table endpoints or vice versa, even inside the same namespace. This is intentional, to stop an engine from treating a CSV pointer as if it had Iceberg guarantees.

Primary source Polaris Generic Table documentation (1.7.0).

Read this as evidence Polaris is positioning itself as a general lakehouse catalog, not narrowly an Iceberg catalog — the REST Catalog spec (Lesson 4) stays the primary, fully-featured path; Generic Tables are a lighter-weight registry for everything else.

Exercise (written, not scripted)

Read the Generic Table documentation linked above, then write 3–4 sentences answering:

If you registered a Delta table as a Generic Table in Polaris, what would break if two engines wrote to it concurrently?
Whose responsibility would that failure be, given what this lesson told you about commit coordination?

Evidence of competence

A correct answer identifies that Polaris does nothing to serialize or detect conflicting concurrent writes on a Generic Table (no commit coordination), so two engines racing to write the same underlying Delta table would rely entirely on Delta's own concurrency control (or the engines' coordination), not anything Polaris enforces — unlike an Iceberg table in Polaris, where the REST catalog's commit protocol is the referee.

Common failure modes Assuming a Generic Table gets the same optimistic-concurrency safety as an Iceberg table just because it's "in Polaris" — it explicitly does not. Also: trying to DROP TABLE a Generic Table through an Iceberg-table code path (or a client library that assumes every catalog table is Iceberg) and hitting a confusing not-found/type-mismatch error instead of a clear "wrong API for this table type" message.

Retrieval check

What does a Generic Table entity actually store about the underlying table?

Correct. Polaris deliberately doesn't parse or store Delta's/CSV's internal structure for a Generic Table — it's a directory entry, not a schema-aware catalog record.

Not quite. Generic Tables deliberately omit schema and partition spec — that's exactly what distinguishes them from Iceberg tables in Polaris.

Two engines concurrently write to a Delta table registered in Polaris as a Generic Table. Who resolves the conflict?

Correct. Generic Tables get no commit coordination from Polaris — that responsibility falls entirely on the table format's own concurrency control or the engines involved.

No. Polaris explicitly does not coordinate commits for Generic Tables — only Iceberg tables get that protection through the REST catalog's commit protocol.

New terms — Generic Table, commit coordination, credential vending — are in the glossary.

Ask the agent: "If a Generic Table gets no credential vending, how does an engine actually get permission to read the underlying files — does it need its own separate storage credentials?" Next lesson zooms out from a single Polaris instance to a Polaris instance that fronts other catalogs: Catalog Federation.