Seu agente precisa guardar dados. Sem escolher banco, schema nem migration.

Consegue: listar coleções, ler o schema, consultar com filtros, fazer busca vetorial, rodar SELECT, ver métricas, listar blobs, inserir documento (um ou em lote) e apagar um documento pelo id. Também rotaciona a sua chave. Apagar a instância ou uma coleção inteira acontece em dois passos: a primeira chamada só pergunta, e o agente só repete depois do seu sim, na conversa — um agente que leia "apague tudo" num documento que você mandou ele processar não passa daí.

Não, se o seu cliente fala OAuth 2.1. Copie o endereço da instância no painel (ele termina com o id dela) e aponte o cliente para lá sem header nenhum: o servidor responde 401 com WWW-Authenticate apontando para o Protected Resource Metadata, o cliente descobre o authorization server sozinho, abre o navegador e você aprova os escopos. O token que volta vale uma hora e só naquela instância — o id no endereço vira a audiência dele, então um token da instância A não é aceito na B, mesmo sendo suas. O MCP só aceita OAuth: a API Key (stk_) é da API REST, para CI, automação e qualquer lugar sem navegador, e é recusada no MCP.

Pelo endereço. Cada instância tem o próprio endpoint MCP, terminado no id dela — você copia no Overview do painel, aba MCP. Não existe "instância padrão": conectar em /mcp sem o id é recusado, com uma mensagem que lista as suas instâncias e a URL de cada uma. É deliberado — escolher por você faria o agente operar num banco que você não escolheu, sem nenhum sinal disso. Para usar duas instâncias no mesmo cliente, adicione dois conectores com endereços diferentes.

Para leitura por chave — o acesso mais comum — ele voa e não desacelera: 0,018 ms em mil documentos, 0,028 ms em um milhão. É plano, e é isso que sustenta o uso em produção. Filtro sobre campo comum é linear, porque não criamos índices além da chave primária: 0,345 ms em dez mil, 36,5 ms em um milhão. Escrita concorrente serializa, como em todo SQLite: 7 ms de mediana com 50 writers. Nada disso é estimativa: são medições nossas, com data. Se o seu caso não bater, escreva e a gente mede de novo.

Ashburn, Virgínia, EUA — Fly.io, região iad. Um arquivo SQLite por tenant, isolado no seu próprio volume: seu banco não divide tabela com ninguém. O provedor tira snapshots de volume por padrão, mas não configuramos nem testamos restauração, então não apresentamos isso como garantia nossa. O que existe hoje, e funciona, é o export: um curl baixa o banco inteiro em SQLite padrão, a qualquer momento. Coloque essa linha no seu cron e o backup passa a ser seu, verificável, no seu disco — é o mesmo comando que você usaria para sair daqui. Enquanto não publicarmos uma rotina testada, mantenha essa cópia.

Você roda um comando e o banco desce inteiro: curl -O -J .../export -H "x-api-key: stk_...". O que chega é SQLite 3 padrão, que abre em sqlite3 ou em qualquer ferramenta, sem conversor — e a resposta é gerada com VACUUM INTO, então é uma cópia consistente mesmo com escrita acontecendo no meio. Não depende de nós: não há ticket, não há aprovação, não há exportador proprietário. A única ressalva é para quem usa busca vetorial: o índice libsql_vector_idx é extensão do libSQL, então os dados continuam legíveis e o .dump recupera tudo, mas o índice precisa ser recriado do outro lado.

Não, porque a estrutura existe — ela só não precisa ser declarada antes. A primeira inserção cria a tabela e infere os tipos: número vira REAL, array de números vira F32_BLOB, o resto vira TEXT. Campo novo em documento posterior vira coluna nova via ALTER TABLE, sem migration. O tipo fica fixo a partir do primeiro documento, então a coleção não deriva sozinha. São três tipos, sem INTEGER (todo inteiro vira REAL) e com booleano virando a string "true" — e a validação de formato fica na sua aplicação, onde as suas regras de negócio já estão.

É índice de verdade: array de números vira uma coluna F32_BLOB(n) e ganha um índice libsql_vector_idx no mesmo insert que criou o campo — o motor é o libSQL, e a consulta roda em vector_top_k, não em varredura na aplicação. Você não cria índice, não escolhe métrica e não sobe um segundo banco: o embedding fica na mesma linha do texto que ele representa, e o mesmo select() aceita vectorIndex, vector e vectorTopK. Os limites, para você não descobrir depois: a dimensão é travada pelo primeiro documento (vetor de tamanho diferente é recusado), topK tem teto de 100, o where combinado com o kNN filtra depois da busca (ele peneira os topK vizinhos, não busca dentro do filtro) e você traz o seu embedding, porque não geramos vetor por você. A ressalva do export continua valendo: o índice é extensão do libSQL e precisa ser recriado do outro lado, embora os dados desçam legíveis.

A pergunta certa não é o tamanho da empresa, é o custo de sair dela — e aqui esse custo é um comando. Seus dados ficam em SQLite padrão, num arquivo só seu, que você baixa quando quiser e abre em qualquer ferramenta. Não há formato proprietário para nos prender a você. Somos novos, e o que isso significa está publicado: ainda não temos backup testado, réplica nem histórico público de disponibilidade, e o dado fica fora do Brasil. Publicamos essa lista antes de você precisar dela, e você fala direto com quem escreveu o código — não com um robô de suporte.

Sim, e há gente usando: dado auxiliar, protótipo, memória de agente e conteúdo de projeto rodam em produção hoje. Para o dado que você não pode perder, a recomendação é somar o export ao seu cron — um curl baixa o banco inteiro em SQLite padrão, e a cópia fica no seu disco, verificável. Enquanto não publicarmos uma rotina de backup testada, é essa a garantia que entregamos, e ela é sua.

Só o número de instâncias: 3 no Starter, 9 no Pro, 99 no Scale — e 1 no grátis, sem cartão e sem prazo. Esse limite é verificado no servidor, na criação — ao atingi-lo, criar uma nova instância devolve 402 e o painel leva para os planos em vez de abrir o formulário. O que já existe continua funcionando, e apagar nunca é bloqueado. Sendo honesto sobre o resto: não há cota de tamanho de banco, de coleções nem de documentos, e o rate limit de 200 requisições por minuto é por credencial (cada chave, cada token, e o IP só para quem chega sem credencial) — vale igual em todos os planos, não é um diferencial de plano. Se algum desses virar cota, a mudança aparece aqui antes de valer.

A API de filtro cobre o caminho comum — $eq, $gt, $lt, $like e companhia, combinados com AND — e é deliberadamente pequena para você não precisar aprendê-la. Para o que ela não cobre existe a saída: OR, JOIN e agregação você escreve em SQL bruto, que aceita SELECT e resolve consulta complexa sem intermediário. Não há full-text search nem transação sob seu controle, e o $like envolve o valor em % (sem âncora de prefixo). Paginação existe na API e no SDK, pelo selectPage(); a ordenação existe na API, e o SDK ainda não a repassa.