Feature request: Dependent Data Hydration ("Graph Sync") for Sliding Window Patterns

[dsanmart]

Is your feature request related to a problem? Please describe.
I am building a local-first mobile application (React Native) involving high-frequency data (messaging) where we need to sync a "sliding window" of recent activity (e.g., messages WHERE created_at > 30 days ago).

The problem is Data Hydration (orphaned Foreign Keys). When we sync the last 30 days of messages, we also need the Conversation and Customer rows associated with those messages to render the UI. However:

1. The Conversation might be 2 years old (outside the sync window).
2. Syncing all Conversations is not feasible (dataset too large).
3. We cannot easily identify which old conversations to fetch without first fetching the messages.
   This leaves us with orphaned foreign keys on the client and a broken UI.

Describe the solution you'd like
I would like a mechanism to define Dependent Shapes or Include Trees where the presence of a child row in a shape forces the sync of its parent row, regardless of the parent's timestamp.

Ideal Syntax (Conceptual):

const { data } = useShape({
  table: 'messages',
  where: `created_at >= now() - interval '30 days'`,
  include: {
    // Automatically fetch the specific Conversation row referenced by messages.conversation_id
    conversation: {
      include: {
        // And the Customer referenced by that conversation
        customer: true
      }
    }
  }
})

I understand include was removed in v1.0, but the use case for "Graph Sync" remains critical for partial replication.

Additional context

• Stack: Postgres -> ElectricSQL -> SQLite

[balegas]

You can use subqueries for that. We have a new subqueries algorithm that doesn't trigger 409s. You can enable it with the tagged_subqueries feature flag.

To avoid loading entire history of data you can also use the on-demand sync mode from Tanstack DB

[dsanmart]

Thanks @balegas. That sounds exactly like what I need.

Regarding TanStack DB - I saw the 0.5 announcement, but since it is still in Beta, we cannot risk using it for our production application just yet. We need a stable solution within the current ecosystem.

I'd love to see the docs or an example for tagged_subqueries.

To give you context, I am aiming for a Hybrid Sync Strategy to keep the local DB small but consistent. I want to validate if this fits the new subqueries algorithm:

1. The "Hot" Window (Electric): I want to sync messages where updated_at > 30 days.

2. Graph Integrity (The Challenge): If a message falls into that window, I must sync its parent conversation row to render the UI if it hasn't been synced yet.

• Problem: The conversation itself might be old (updated_at < 30 days).
• Goal: Can tagged_subqueries allow me to define a shape effectively saying: "Sync messages > 30 days AND any conversations referenced by those specific messages"?

3. The "Cold" History (On-Demand): For deep history (e.g. user scrolls back 2 years), I plan to handle that via standard API calls (sideloading) outside of the Electric sync stream.

Does the new tagged_subqueries feature support step 2 (fetching parents based on child criteria)? If so, what would that Shape definition look like? I couldn't find any docs/examples for this.