Mental model: a table is a Delta prefix
How Eddytor maps a table onto your object storage - tables, not files.
Before you create anything, hold this picture in your head: an Eddytor table is a Delta Lake table living at a prefix in your own object storage. Eddytor connects to it - it never copies your data somewhere else.
Tables, not files
You stop thinking in Parquet files and folder layouts. A table is a real object with:
- a schema - typed, nullable-aware columns;
- a transaction log (
_delta_log) - every write is a numbered version you can diff, time-travel, and roll back; - governance - column domains and constraints, stored as metadata on the table itself.
Underneath, that's a set of Parquet data files plus a _delta_log directory at a
prefix like s3://your-bucket/master-data/products/. Eddytor manages those for
you - you operate on the table.
What lives where
| Where it lives | |
|---|---|
Your table data (Parquet + _delta_log) | Your object storage bucket/container |
| Eddytor's metadata (users, storage connections, secrets) | Eddytor's Postgres |
| Governance rules (domains, constraints) | Metadata on the Delta table - travels with the data |
Because the data is standard Delta Lake on standard object storage, it stays readable by any Delta-compatible tool even without Eddytor - no lock-in.
Why it matters
This is why connecting storage comes first (Prerequisites), why deleting a table means deleting its prefix (Retire), and why vacuum - which prunes old files - limits how far back you can time-travel.