Frequently asked questions

Your authored lists live in your own tenant in PostgreSQL, behind row-level security that is enabled and forced on every table — not the default RLS Supabase applies automatically, which only covers its own default schema. AutoSugges relations are never created there.

Credential material and internal ledgers — signing keys, usage aggregates, the audit log — live in a separate schema that no API role can reach at all. A policy mistake inside it cannot leak your data, because nothing can address the schema to try.

The runtime autocomplete path that actually answers a keystroke never touches PostgreSQL. It reads a compiled, immutable artifact from Cloudflare KV, so there is no live database query to intercept on the hot path at all.

The system of record is Supabase PostgreSQL. Authoring, publishing and control-plane state live there, scoped to your tenant.

Published, compiled artifacts are replicated to Cloudflare Workers KV and served from the edge, because the runtime plane may not depend on PostgreSQL at all. What reaches KV is always the verified output of a publish, never the mutable rows behind it.

The edge returns a structured quota_exceeded response — never a partial result, and never a synthetic or cached-looking item standing in for a real one.

Metering is atomic with the check that decides whether the request is allowed, and it runs before the cache is ever consulted. A request that fails metering has no code path to a cache hit, so quota cannot be bypassed by a warm cache.

Quota-exceeded responses are marked non-cacheable, so an intermediary cannot keep serving them after you upgrade.

There is no hosted-only lock-in by architecture: your data is ordinary PostgreSQL rows in your own schema, not a proprietary format, and the compiler that turns them into runtime artifacts is part of the same codebase rather than a private service.

AutoSugges is built and operated independently, by one person, not a company with a support contract or a funding round behind it. That is a real fact worth weighing, not a promise this page can make disappear: the honest answer is that continuity here rests on the same person who built it, and the mitigations are architectural — your data stays queryable PostgreSQL, and published artifacts are immutable and version-addressed so nothing already running breaks silently.

A database LIKE or ILIKE query hits PostgreSQL on every keystroke — connection overhead, query planning and disk latency for something that should feel instant. AutoSugges compiles lists ahead of time into adaptive 2-to-5-character prefix buckets, so a lookup is a fast key-based read, not a live scan.

A general-purpose search cluster is real operational weight for a narrower problem: running and scaling a separate service to keep warm, for queries that are almost always a short prefix rather than free-text search.

Hosted full-text search products are built for indexing arbitrary documents. AutoSugges is narrower on purpose: it compiles a list into ranked, prefix-addressable buckets, which is what makes the artifacts small enough to serve from the edge with no origin round trip.

A query resolves from pre-compiled artifacts served at the edge, with zero reads on a cache hit. There is no database call and no origin server in the request path — nothing to query live, ever, on the hot path.

Speed comes from doing the expensive part once, at publish time. The compiler ranks and buckets every list ahead of time; the edge only has to look up a bucket that already has the answer in it, never compute one.

Queries pass through the edge Worker to be answered and are not attached to end-user identity — behavioural signals used for ranking identify canonical items and request ids, not people.

Selection events (what somebody picked, to improve future ranking) are recorded as aggregate signal, asynchronously, off the hot path — never synchronously in the response your users wait on.

AutoSugges is designed to minimize personal data by default: the product identifies canonical list items and request ids for ranking, not end-user identities, and does not build per-user personalization or store end-user PII.

See /privacy and /dpa for what is actually collected about you as a tenant — account email, usage aggregates, audit records — and the sub-processors involved.

A publishable key is not a secret and is assumed to be observable — it ships in your client bundle, exactly like any other publishable key pattern. What it carries is scope: which owner, which list, which version, an origin allow-list and a billing identity.

It cannot be used to write, mutate or delete anything, and it cannot reach a private list from an origin that is not on its allow-list. Rate limits and quota are enforced against it at the edge, independent of how many times it is copied, so a leaked key does not buy unbounded reads.

A key can be revoked or rotated at any time; revocation rewrites the edge record directly, so a revoked key stops resolving on its very next request rather than waiting for a cache to expire.

Your authored data is plain PostgreSQL rows you can export at any time — there is no proprietary export format standing between you and your own list.

Because compiled artifacts are the derived output and your source rows are the system of record, leaving means taking your rows elsewhere; nothing about the runtime format is required to keep using them.