> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Limite de persistência

> Como funciona a responsabilidade pelo banco de dados neste repositório e como evoluí-la sem criar dispersão de providers.

# Limite de persistência

Este repositório herda a parte útil da filosofia de banco de dados do `next-forge`, não a stack de provider padrão.

A parte útil é:

* manter a responsabilidade do banco de dados dentro de `@repo/database`
* manter a responsabilidade de auth/sessão dentro de `@repo/auth`
* manter os apps importando limites pertencentes aos packages, em vez de clientes de provider crus

Este repositório é **Supabase-first** e **orientado a migrations SQL**. Ele **não** é atualmente um sistema com abstração de ORM verdadeira.

## Verdade atual

* `packages/database` é o limite de data-plane.
* `packages/auth` é responsável pelos helpers de autenticação Supabase escopados por request e por browser.
* `supabase/migrations` é a fonte da verdade do schema.
* muitas superfícies de runtime ainda rodam através de um adaptador com mock.

O que falta hoje:

* interfaces de repositório estáveis
* uma separação limpa entre os adaptadores mock e Supabase
* um contrato honesto e agnóstico de provider que possamos trocar rapidamente por trás dele

## Regras a seguir

* Coloque acesso a dados em `packages/database`.
* Coloque helpers de auth/sessão em `packages/auth`.
* Não importe `@supabase/supabase-js` diretamente nos apps para trabalho de data-plane.
* Não afirme que o repositório é intercambiável entre ORMs até que as implementações mock e Supabase estejam alinhadas às mesmas interfaces de repositório.
* Quando a persistência mudar, atualize a documentação de migrations e o contrato do package de database juntos.

## Direção da migration

A sequência pretendida é:

1. definir interfaces de repositório em `packages/database`
2. separar os adaptadores mock e Supabase
3. padronizar os scripts de migration raiz e de geração de tipos
4. remover resquícios enganosos do Prisma da orientação ativa
5. manter futuras mudanças de provider ou ORM contidas dentro de `@repo/database`

## Leia a seguir

* [Arquitetura para contribuidores](/pt-BR/contributing/architecture)
* [Desenvolvimento](/pt-BR/development)
* [Plano de migration](/pt-BR/platform/migration)