Environment

• ClickHouse Cloud (SharedMergeTree)
• Client: @clickhouse/client (Node.js, HTTP protocol) via Kysely query builder with @founderpath/kysely-clickhouse dialect
• Table: ~900 rows currently, expected to grow
• ORDER BY: (user_id, id) where id is UUID

Problem

I have a table where users can create, update, and delete reports. After an INSERT or DELETE + INSERT (for updates), I immediately SELECT the row by its id to return it to the client. This sometimes fails with a "no result" error — the row hasn't replicated yet.

Simplified flow (using Kysely):

// INSERT
await db
  .insertInto('user_reports')
  .values({ id, user_id, title, ... })
  .execute()

// SELECT immediately after — sometimes fails with "no result"
const row = await db
  .selectFrom('user_reports')
  .selectAll()
  .where('id', '=', id)
  .where('user_id', '=', userId)
  .executeTakeFirstOrThrow()

Questions

1. Why does session_id not guarantee same-node routing via HTTP in ClickHouse Cloud? Is sticky routing based on session_id supported, or is it only guaranteed with the native protocol?

2. What is the recommended approach for read-after-write in SharedMergeTree? For a low-volume CRUD table (~hundreds to low thousands of rows), is SYSTEM SYNC REPLICA LIGHTWEIGHT before each critical read acceptable, or is there a lighter-weight solution?

3. Would select_sequential_consistency = 1 on the individual SELECT query be more appropriate than SYSTEM SYNC REPLICA LIGHTWEIGHT? What's the relative overhead of each?

Thank you!