Keep the application’s source intact
If your application already uses Supabase Postgres, the retrieval project does not need to become a second application backend. Polygres can synchronize selected tables and provide retrieval tools while your application keeps writing to its source.
Start by identifying a useful slice of data. For a support workflow, that might be knowledge passages, cases, and the account identifiers needed to connect them. Keep unrelated tables outside the initial scope.
Use the right connection path
Replication needs a suitable direct Postgres connection. A transaction pooler endpoint is not interchangeable with the source connection used for logical replication. Follow the current Supabase source setup instructions for connection details and permissions.
Check network access, TLS, and the source user’s privileges before selecting tables. Do not put source credentials in browser code, client-side examples, or a public repository.
Give rows an identity
Updates need a stable way to identify the source row. Review table eligibility and primary-key or supported unique-identity requirements before relying on synchronization.
Think about identity at the document level as well. If you split a knowledge document into passages, preserve the document identifier and passage identifier so a retrieved result can lead back to its source.
Verify the useful path
After the initial snapshot, confirm the synchronized project is ready. Change a small test record at the source and inspect the resulting project state before building the larger retrieval workflow.
Configure AI Context collections or graph relationships around your chosen questions. Your application still owns user access and presentation; synchronizing Postgres data does not automatically reproduce every application-level authorization rule.
Explore the next step
Continue with the platform guide. For the current setup and API contract, use the Polygres documentation.