Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

FIM One supporte deux backends de base de données : SQLite (par défaut, zéro configuration) et PostgreSQL (recommandé pour la production). Le backend est déterminé par la variable d’environnement DATABASE_URL. 
# SQLite (default — no configuration needed)
DATABASE_URL=sqlite+aiosqlite:///./data/fim_one.db

# PostgreSQL (production)
DATABASE_URL=postgresql+asyncpg://user:pass@localhost:5432/fim_one
Les tables sont créées automatiquement au premier démarrage — aucune étape de migration manuelle n’est requise.

​
SQLite vs PostgreSQL

SQLitePostgreSQL
ConfigurationZéro configuration, basé sur fichierNécessite un serveur séparé
ConcurrenceÉcrivain unique (verrou global)MVCC complet, verrouillage au niveau des lignes
Multi-workerNon supporté (WORKERS doit être 1)Entièrement supporté
Streaming SSELes connexions maintenues pendant les flux peuvent bloquer d’autres requêtesLes lectures et écritures concurrentes ne sont pas affectées
SauvegardeCopier le fichier .dbpg_dump ou réplication en continu
Idéal pourDéveloppement, utilisateur unique, démosProduction, multi-utilisateurs, équipes
Développement local : SQLite fonctionne directement — pas de serveur de base de données, pas de Redis, rien à configurer. Commencez simplement à coder.Production : Déployez avec Docker Compose et PostgreSQL + Redis sont provisionnés automatiquement. Aucune configuration manuelle de base de données nécessaire.

​
Limitation connue : Streaming concurrent SQLite

SQLite peut devenir un goulot d’étranglement sous charge concurrente.FIM One utilise Server-Sent Events (SSE) pour le streaming des réponses IA. Pendant le streaming, chaque connexion SSE active maintient une connexion de base de données du pool pendant toute la durée du stream. SQLite applique un verrou d’écriture global, ce qui signifie qu’une seule opération d’écriture peut procéder à la fois — toutes les autres écritures s’accumulent derrière elle.Bien que le pool de connexions supporte jusqu’à 30 connexions simultanées (pool_size=20 + max_overflow=10), le goulot d’étranglement est le verrou lui-même, pas le pool. Quand plusieurs utilisateurs discutent simultanément, leurs opérations d’écriture (sauvegarde des messages, mise à jour des compteurs de jetons) se sérialisent les unes contre les autres.Symptômes que vous pourriez observer :
  • La liste de conversations se charge lentement pendant qu’un autre utilisateur effectue un streaming
  • Les pages de paramètres semblent lentes pendant les sessions de chat actives
  • Les réponses API sont retardées quand plusieurs streams sont actifs
Recommandation : Si vous avez plus de 2-3 utilisateurs concurrents, passez à PostgreSQL. PostgreSQL utilise MVCC (Multi-Version Concurrency Control) avec verrouillage au niveau des lignes, de sorte que les lectures et écritures concurrentes procèdent indépendamment sans se bloquer mutuellement.

​
Configuration du pool de connexions

FIM One configure les paramètres du pool de connexions SQLAlchemy en interne pour chaque backend. Ce sont des valeurs par défaut optimisées qui ne nécessitent pas de variables d’environnement — elles sont appliquées automatiquement en fonction du schéma DATABASE_URL. Les comprendre aide à expliquer le comportement à l’exécution.

​
Paramètres du pool SQLite

ParamètreValeurDescription
pool_size20Nombre de base de connexions persistantes dans le pool
max_overflow10Connexions supplémentaires créées sous charge (jusqu’à 30 au total)
Mode journal WALActivéWrite-Ahead Logging permet les lectures concurrentes pendant qu’une écriture est en cours, réduisant considérablement la contention des verrous
busy_timeout30sLorsque le verrou d’écriture est maintenu, les autres écrivains attendent jusqu’à 30 secondes avant de lever une erreur, au lieu d’échouer immédiatement
synchronousNORMALSûr en mode WAL ; offre un meilleur débit d’écriture que le FULL par défaut
Le mode WAL et le délai d’attente de 30 secondes sont définis via les PRAGMAs SQLite sur chaque nouvelle connexion. Cette combinaison garantit que les lectures de courte durée (chargement d’une liste de conversations, récupération des paramètres) ne sont pas bloquées par les transactions d’écriture longue durée, et que les écritures concurrentes s’ajoutent à la file d’attente correctement au lieu d’échouer.

​
Paramètres du pool PostgreSQL

ParamètreValeurDescription
pool_size10Nombre de base de connexions persistantes dans le pool
max_overflow20Connexions supplémentaires créées sous charge (jusqu’à 30 au total)
pool_timeout30sTemps maximum d’attente pour une connexion libre du pool avant de lever une erreur de timeout
pool_recycle1800sLes connexions sont recyclées toutes les 30 minutes pour éviter les connexions obsolètes (important pour les bases de données hébergées dans le cloud qui ferment les connexions inactives)
PostgreSQL gère la concurrence nativement via MVCC, donc les paramètres du pool contrôlent principalement l’utilisation des ressources plutôt que la contention. L’intervalle de recyclage de 30 minutes évite les problèmes avec les pare-feu, les équilibreurs de charge ou les services de base de données gérés qui ferment silencieusement les connexions TCP inactives.

​
Passage à PostgreSQL

​
Étape 1 : Démarrer une instance PostgreSQL

Le moyen le plus rapide est d’utiliser Docker : 
docker run -d \
  --name postgres \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_DB=fim_one \
  -p 5432:5432 \
  postgres:16-alpine

​
Étape 2 : Définir DATABASE_URL

Ajoutez ou mettez à jour la ligne suivante dans votre fichier .env : 
DATABASE_URL=postgresql+asyncpg://postgres:secret@localhost:5432/fim_one

​
Étape 3 : Redémarrer FIM One

# Local development
./start.sh portal

# Or restart your process manager / systemd service
Les tables sont créées automatiquement au premier démarrage. Aucune migration de schéma manuelle n’est nécessaire.
Les données SQLite existantes ne sont pas migrées automatiquement. Le changement de DATABASE_URL de SQLite à PostgreSQL commence avec une base de données vierge. Si vous avez des conversations, agents ou connecteurs existants dans SQLite que vous devez conserver, consultez la section Migration de données ci-dessous.

​
Docker Compose (Recommandé pour la production)

Si vous déployez avec Docker Compose, PostgreSQL et Redis sont déjà inclus et configurés automatiquement — il n’y a rien d’extra à configurer. Le docker-compose.yml définit DATABASE_URL en interne — votre valeur .env est remplacée : 
environment:
  DATABASE_URL: postgresql+asyncpg://fim:fim@postgres:5432/fim_one
Aucune configuration de base de données supplémentaire n’est nécessaire lors de l’utilisation de Docker Compose.

​
Migration de données

Il n’existe pas d’outil de migration intégré de SQLite vers PostgreSQL. Pour la plupart des déploiements, l’approche recommandée dépend de votre situation : Déploiement nouveau (pas de données existantes) : Définissez simplement DATABASE_URL sur votre chaîne de connexion PostgreSQL et démarrez FIM One. Toutes les tables sont créées automatiquement. Données existantes qui doivent être conservées : Une export/import manuelle est requise. L’approche générale :
  1. Exportez les données de SQLite en utilisant un outil comme l’interface de ligne de commande sqlite3 ou un script Python
  2. Transformez les données selon les besoins (SQLite et PostgreSQL ont des différences de type mineures)
  3. Importez dans PostgreSQL en utilisant psql, pg_restore, ou des scripts d’insertion au niveau de l’application
Pour la plupart des utilisateurs effectuant une mise à niveau d’une configuration de développement vers la production, il est plus simple de recommencer avec PostgreSQL et de recréer vos agents et connecteurs via l’interface utilisateur. L’historique des conversations n’est généralement pas assez critique pour justifier une migration manuelle.