Skip to content

Docs updates in preparation for the Sync Streams beta release#349

Merged
benitav merged 76 commits intomainfrom
sync-stream-beta
Mar 3, 2026
Merged

Docs updates in preparation for the Sync Streams beta release#349
benitav merged 76 commits intomainfrom
sync-stream-beta

Conversation

@benitav
Copy link
Collaborator

@benitav benitav commented Feb 5, 2026

Details are in this internal doc https://docs.google.com/document/d/1oP0UNOjpsfSrQ1a2WIhG0A0DYeWU1tTIGZqMMKuqzdE/edit

At a high level, this prioritizes Sync Streams over Sync Rules throughout the documentation and labels Sync Rules as legacy, updates alpha references to beta, fleshed out Sync Streams docs, and also documents new features (e.g. nested subqueries, JOIN syntax, CTEs) that have been added since the alpha release (though not yet released).

Also includes some general polish:

  • Sync Streams and Sync Rules casing was made consistent
  • sync_rules.yaml references were renamed to sync_config.yaml to better cater for both Streams and Rules
  • Added mdx descriptions to pages where I noticed they were missing
  • Renamed "dynamic partial replication" to "partial sync"

@cahofmeyr
Copy link
Collaborator

When I reviewed the Sync Streams "Quickstart" page, and it explained user-scoped data and parameterized data, I felt we could simplify that because we want to reduce the overall number of new concepts that the user feels they need to go through.

When talking about parameterized data, we referred exclusively to using subscription parameters, but:

  • User-scoped data referred to using JWT claims, but if you use something like a org ID or project ID from a JWT, that feels like just another form of parameterized data.
  • Even just using a user ID feels like a specific case of parameterizing data.
  • Using connection parameters would also be another form of parameterized data.

I ended up editing that section a bit and collapsing the Using Parameters section into it.

@powersync-ja powersync-ja deleted a comment from cahofmeyr Feb 17, 2026
@cahofmeyr
Copy link
Collaborator

@benitav Suggestions for improvements to the Supported SQL page:

Operators and Functions

When filtering on parameters, operators can only be used in a limited way. Typically only =, IN and IS NULL are allowed on the parameters, and special limits apply when combining clauses with AND, OR or NOT.

I think we should be as specific as possible. Remove "typically" and "special limits apply" and rather say exactly what is and what is not supported (and distinguish Sync Rules vs Sync Streams respectively, if they differ)

Operators

"Arrays:" says the following:

Returns true if the left value is present in the right JSON array.
In data queries, only the left value may be a bucket parameter. In parameter queries, the left or right value may be a bucket parameter.
Differs from the SQLite operator in that it can be used directly on a JSON array.

This seems to be specific to Sync Rules (and uses Sync Rules terminology). Can we update that section to specify what is supported in Sync Streams vs. Sync Rules w.r.t. arrays and the IN operator?

Copy link
Contributor

@simolus3 simolus3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've mostly looked at the examples for sync streams, comparing them with the diff of original sync rules.

One thing that stands out is the use of a global with block that isn't supported (see the original PR for details). Apologies for that, I don't think we've communicated that limitation clearly and I know the original doc says something else :/

@benitav benitav merged commit 0e9d7b4 into main Mar 3, 2026
4 checks passed
@benitav benitav deleted the sync-stream-beta branch March 3, 2026 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants