Skip to content
FIRERUN.

The BaaS & deploy-platform newsroom for builders

Subscribe

Supabase

Supabase Realtime Now Sends Only the Columns You Ask For

Supabase's Postgres Changes now supports AND filters, more operators and opt-in column selection, cutting bytes sent to Realtime subscribers.

Abstract flat-vector editorial illustration for "Supabase Realtime Now Sends Only the Columns You Ask For"

Supabase’s Postgres Changes, the Realtime feature that streams database row changes to subscribed clients, now lets developers filter which rows go out with AND logic and trim which columns go out with an opt-in select, according to the Supabase blog, published August 5, 2026. Until now, a subscription could narrow which rows it heard about, but every matching row still shipped in full.


What shipped

Three changes landed together. Filters that used to be comma-separated conditions now formally compose with AND, matching the syntax the Supabase client libraries already use elsewhere. The filter operator set grew too: like and ilike for pattern matching, is for null and boolean checks, match and imatch for POSIX regular expressions, and isdistinct for NULL comparisons.

The bigger change is column selection. Adding a select option to a subscription means only the named columns come back in the payload, instead of the entire row. The table’s primary key is always included even if it’s left out of the list, so a client can still identify which row changed without asking for the key explicitly.

Column selection is opt-in. Existing subscriptions keep getting full rows until a select is added, so nothing breaks by upgrading. It does require @supabase/supabase-js 2.109.0 or newer; the filter changes work against whatever client version is already in use. Only AND composition shipped, so OR filtering across conditions still isn’t supported.

Why it matters: Realtime bills on bytes

Supabase bills Realtime on messages and egress. A subscription that used to receive a full row on every update (including columns the client never reads) was paying for bytes it discarded. Column selection turns that into an explicit choice: a presence indicator that only needs user_id and status no longer pulls a bio field or a JSON blob along for the ride.

For anything high-frequency, like live cursors, telemetry streams or dashboards built on wide tables, that’s a direct cost and bandwidth reduction with no architecture change required, just adding select to an existing subscription call.

The take

This is the kind of update that doesn’t make a keynote but should still get budgeted time: it’s a low-risk, opt-in change with a clear bill impact for anyone running high-volume Realtime subscriptions on wide tables. The AND-only limitation on filters still matters if your access pattern needs OR logic. Supabase hasn’t said when or if that’s coming. But for the common case of “give me only the columns I render,” this closes a gap that’s existed since Postgres Changes launched.

Stay in the loop

Get new articles in your inbox

We'll only email you when a new article drops. Unsubscribe anytime.