Configurable field visibility for realtime subscriptions

[shinypb]

Feature request

I would like to receive realtime updates for a table without exposing all of the fields within a given row. Allow me to explain a simplified version of what I am trying to build.

I have API endpoints for creating, reading, and writing to KeyValue objects, which are just key-value stores. Users should be able to share either write or read-only access to these objects with other users. My schema looks something like this:

model KeyValue {
  id       String  @id @default(cuid())
  data     Json
  readKey  String  @default(cuid())
  writeKey String  @default(cuid())
}

Access to a particular KeyValue instance gated by the use of either the readKey or the writeKey; a user can create an KeyValue object and give another user read-only access by sharing its id and the readKey with them.

Having realtime updates for this system is desirable, but Supabase's current implementation means that the writeKey would be visible to anyone with the readKey, which defeats the point.

Describe the solution you'd like

Within the Supabase UI, I'd like to be able to block particular fields from ever being included in realtime updates.

Describe alternatives you've considered

I could work around the lack of field visibility controls by breaking my object up into two tables; something like...

model KeyValue {
  id       String       @id @default(cuid())
  readKey  String       @default(cuid())
  writeKey String       @default(cuid())
  data     KeyValueData @relation(fields: [readKey], references: [readKey])
}

model KeyValueData {
  readKey    String @unique
  keyValueId String
  data       Json
  KeyValue   KeyValue[]
}

In this universe, I can subscribe to realtime updates on the KeyValueData table without leaking sensitive data. However, this is a bit of a contortion to satisfying the system, and I'd prefer to keep things in a single table if possible.

[w3b6x9]

@shinypb Thanks for the feature request! We're currently working on Multi-Tenant Realtime and will consider adding your feature request to the roadmap.

[shinypb]

Thanks for the quick response, @w3b6x9. It occurred to me earlier this morning that a simple “include data values in Realtime events” checkbox would cover my use case. Being able to receive notifications of which fields changed without actually including the changed values seems like it might be simpler to implement and reason about than having per-field visibility.

[chasers]

Quick update on this, yeah this is something we could do with column level security baked into Postgres. We're close to releasing the latest version of Realtime. Once we've merged that into this repo we will revisit these enhancements.