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 the public schema. AutoSugges relations are never created in public.

Credential material and internal ledgers — signing keys, usage aggregates, the audit log — live in a second schema, autosugges_private, 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 runs in a Durable Object, atomically 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 or a KV read, 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 KV read, not a live scan.

Typesense is deliberately not used at all. Running and scaling a separate search cluster is real operational weight for a problem that, at autocomplete scale, a compiled edge artifact answers without a server to keep warm.

Algolia and similar hosted search services are general full-text search products. AutoSugges is narrower on purpose: it compiles a list into ranked, prefix-addressable buckets rather than indexing arbitrary documents, which is what makes the artifacts small enough to serve from the edge with no origin round trip.

A query resolves in at most two KV reads on a cache miss — one for the key/context record, one for the prefix bucket — and zero on a cache hit. There is no database call and no origin server in the request 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 Phase 1 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.