Frequently asked questions
Find answers to common questions about access, missing rows, uncertain uploads and interrupted streams. Start with the result you expected, then follow the linked guide for your interface. Keep the original input after an uncertain write: an empty query or lost response does not prove that the service rejected it.
Access and connections
Section titled “Access and connections”Why can’t I sign in?
Section titled “Why can’t I sign in?”Check which sign-in methods your deployment enables, then follow the sign-in checks. A successful sign-in establishes your identity; catalog access is a separate permission check.
Why did my database connection stop working?
Section titled “Why did my database connection stop working?”PGWire uses temporary database credentials. Check their expiry and obtain a fresh login when needed. See connection failures.
Why is my catalog missing or access denied?
Section titled “Why is my catalog missing or access denied?”Confirm the catalog UUID and your membership or grant. A catalog name or local alias does not grant access. Native DuckDB also needs an explicit attachment after discovery. See catalog permissions and native DuckDB setup.
Writes and query results
Section titled “Writes and query results”Why can’t I see rows after sending them?
Section titled “Why can’t I see rows after sending them?”Acceptance, local commit and table publication are different results. Check the visibility boundary for your query client. An early empty result is not a reason to send the same input again.
Why did an HTTP upload accept fewer rows than I sent?
Section titled “Why did an HTTP upload accept fewer rows than I sent?”The current HTTP path admits a validated request as one group. If the returned count is unexpectedly smaller, keep the input and returned count, then reconcile the outcome before replaying it. The count does not identify accepted row positions. See unexpected row counts.
Can I retry a write if the response was lost?
Section titled “Can I retry a write if the response was lost?”The service may already have accepted some or all of the input. Keep the original payload and reconcile before replaying; a retry can create duplicates. Follow the retry guidance.
Why does search show no new results?
Section titled “Why does search show no new results?”Search index progress is separate from source-table visibility. Check search visibility rather than treating a successful write as proof that the index is ready.
Streams and recovery
Section titled “Streams and recovery”What should I do when a live stream is interrupted?
Section titled “What should I do when a live stream is interrupted?”Preserve the exact opaque cursor. Catch-up is bounded: if the server sends
refresh-required, close the subscription and rebuild application state instead of
retrying the same cursor. Follow SSE recovery.
Why can’t the cluster serve metadata operations?
Section titled “Why can’t the cluster serve metadata operations?”Metadata-dependent operations need a healthy majority. Check peer health and cluster availability. A readiness or quorum issue is not solved by repeatedly submitting the same write.
Can I recover after losing all local cluster state?
Section titled “Can I recover after losing all local cluster state?”Recovery requires a completed backup and the original cluster identity, keys and storage configuration. Its recovery point may be earlier than the latest accepted input. Follow the cluster recovery procedure.
Gather useful context
Section titled “Gather useful context”Record the client and server versions, endpoint, operation, time, status and sanitized error message. Keep tokens, passwords and credential-bearing URLs out of logs and support messages. For a write, preserve the original input and any response count so you can reconcile it.