# Proposal: Virtual Storage Columns (Seamless DB-to-Storage Mapping)

[purushottam2004]

The Problem: Storage vs. Database Friction

Currently, managing files in Supabase requires developers to bridge two distinct mental models: the Relational Database and Object Storage. This creates several DX hurdles:

1. Multi-step Workflows: Developers must upload a file, wait for a path/URL, and then perform a second update or insert to the database.
2. Syncing Permissions: Security logic often has to be duplicated—once for the Database RLS and once for the Storage Bucket RLS.
3. Binary Inefficiency: To avoid the complexity above, some developers store files as BYTEA (binary) directly in tables, which is inefficient and scales poorly.

The Solution: Virtual Storage Columns

I am proposing a Mapping Layer that allows developers to treat storage objects as first-class citizens within a PostgreSQL table.

Under the hood, it uses existing Storage buckets, but the "mental model" is that of a simple table column.

How it Works

• The Column: We introduce a specific column type (e.g., storage_link). It stores a unique Short ID or pointer to a file in a managed bucket.
• Automatic RLS Inheritance: Security is simplified. If a user has SELECT access to the row, they are automatically granted access to the storage object. The "Virtual Column" acts as a gatekeeper.
• Client-Side "Boom": On the frontend, the user simply adds a file to a row. The SDK handles the upload and the linking in a single conceptual transaction.

Comparison Table

Feature	Current Manual Workflow	Virtual Storage Column
Logic	Two-step (Upload then Update)	One-step (Insert File to Row)
Security	Redundant RLS (Bucket + Table)	Inherited RLS (Table-driven)
Management	Manual path/URL handling	Automated mapping layer
Developer Focus	Infrastructure orchestration	Data and UI

Developer Experience (DX) Impact

By introducing this abstraction, "Storage" effectively disappears from the developer's mental load. You no longer manage buckets or paths; you manage data. This significantly lowers the barrier to entry for apps that handle heavy user-generated content (profile pictures, documents, etc.).

Implementation Ideas

• Orphan Management: When a row is deleted, the virtual column could trigger a background job to purge the mapped object in Storage.
• Signed URLs: The API could automatically return a signed URL for these columns, removing the need for extra lifecycle management on the client.

---

What do you think? Would this be better as a new column type in the Dashboard, or a set of PostgreSQL extensions/hooks?