What's changing: PowerSync Service adds an optional object storage (S3-compatible) backend for bucket data when using MongoDB storage's experimental V3 format, keeping metadata in MongoDB while moving operation batches to object storage. It's opt-in at the configuration level; when not configured, all operations remain inline in MongoDB as before. A same-day follow-up makes the storage.object_storage.region setting optional (inferred by the AWS SDK where possible) and storage.object_storage.force_path_style explicitly configurable instead of inferred from the endpoint, and another follow-up adds support for clearing object storage data on teardown.
High priority — existing docs are now inaccurate or incomplete
None identified. Filing under the waiver: the hard precondition isn't met (this is an optional, experimental capability, and no existing docs page describes or contradicts it), but it's a meaningful new capability with no current coverage.
For reviewer consideration — may be worth documenting
- Self-Hosted PowerSync Service configuration (
https://docs.powersync.com/configuration/powersync-service/self-hosted-instances) — the "Bucket Storage Database" section documents exactly two storage.type options, mongodb and postgresql (with dedicated "MongoDB Storage" and "Postgres Storage" subsections). It doesn't mention the new storage.object_storage block (S3-compatible object storage for MongoDB storage's V3 format), or its region and force_path_style options. Since this is explicitly experimental (V3 format only) and optional, a reviewer may want to hold off on documenting it until it's promoted out of experimental status, or add a brief experimental-status note now.
Source PR: powersync-ja/powersync-service#728
Related same-day PRs on the same feature: powersync-ja/powersync-service#737 (makes region optional and force_path_style configurable) and powersync-ja/powersync-service#735 (clears object storage data on teardown).
Filed automatically by Claude Code (claude-sonnet-5). A human must verify the scope, prepare the docs PR, and publish it only once this update has been released.
What's changing: PowerSync Service adds an optional object storage (S3-compatible) backend for bucket data when using MongoDB storage's experimental V3 format, keeping metadata in MongoDB while moving operation batches to object storage. It's opt-in at the configuration level; when not configured, all operations remain inline in MongoDB as before. A same-day follow-up makes the
storage.object_storage.regionsetting optional (inferred by the AWS SDK where possible) andstorage.object_storage.force_path_styleexplicitly configurable instead of inferred from the endpoint, and another follow-up adds support for clearing object storage data onteardown.High priority — existing docs are now inaccurate or incomplete
None identified. Filing under the waiver: the hard precondition isn't met (this is an optional, experimental capability, and no existing docs page describes or contradicts it), but it's a meaningful new capability with no current coverage.
For reviewer consideration — may be worth documenting
https://docs.powersync.com/configuration/powersync-service/self-hosted-instances) — the "Bucket Storage Database" section documents exactly twostorage.typeoptions,mongodbandpostgresql(with dedicated "MongoDB Storage" and "Postgres Storage" subsections). It doesn't mention the newstorage.object_storageblock (S3-compatible object storage for MongoDB storage's V3 format), or itsregionandforce_path_styleoptions. Since this is explicitly experimental (V3 format only) and optional, a reviewer may want to hold off on documenting it until it's promoted out of experimental status, or add a brief experimental-status note now.Source PR: powersync-ja/powersync-service#728
Related same-day PRs on the same feature: powersync-ja/powersync-service#737 (makes
regionoptional andforce_path_styleconfigurable) and powersync-ja/powersync-service#735 (clears object storage data onteardown).Filed automatically by Claude Code (
claude-sonnet-5). A human must verify the scope, prepare the docs PR, and publish it only once this update has been released.