osFoundry / Platform
Postgres par application
Chaque application obtient son propre Postgres avec pgvector et TimescaleDB. Ne payez que ce que vous stockez.
Présentation
Postgres par app donne à chaque application que vous construisez dans osFoundry sa propre base Postgres dédiée, au lieu de forcer toutes les apps à partager un schéma ou une connexion unique. Chaque base est livrée avec pgvector pour stocker et interroger des embeddings et avec TimescaleDB pour les données de séries temporelles, si bien qu'une seule base peut contenir vos tables relationnelles, vos vecteurs de recherche sémantique et vos métriques ou flux d'événements sans greffer de services séparés. Vous apportez vos propres clés de modèle pour tout ce qui génère ces embeddings ; le Postgres qui les stocke est provisionné par app.
Comme chaque app est isolée dans sa propre base, le schéma, les index et les données d'une app ne peuvent pas entrer en collision avec ceux d'une autre. Cette isolation rend les apps plus faciles à raisonner, plus sûres à faire évoluer et plus propres à démonter : quand une app disparaît, sa base disparaît avec elle. Au sein d'osFoundry, cela se situe dans la couche Apps et Backend, de sorte qu'une app que vous construisez obtient un vrai magasin de données comme backend plutôt qu'un stockage clé-valeur de fortune, et la même base est disponible pour le code côté serveur de l'app, pour sa recherche vectorielle et pour ses requêtes de séries temporelles. osFoundry est un espace de travail BYOK et local-first, ce qui suit le même principe qui traverse tout le produit : vos données et l'infrastructure sur laquelle elles reposent restent les vôtres, et aucun frais par siège ne vient s'y ajouter.
Le tarif suit ce que vous utilisez réellement. Vous ne payez que ce que vous stockez, si bien qu'une app qui contient quelques milliers de lignes coûte en conséquence, et qu'une app qui ne remplit jamais sa base n'est pas facturée comme si elle le faisait. Cela rend viable de donner par défaut à chaque app son propre Postgres, même aux petites ou aux expérimentales, plutôt que de rationner les bases pour économiser. pgvector et TimescaleDB font partie de la base que vous avez déjà, ce ne sont pas des options avec une ligne de facturation à part.
Fonctionnalités clés
- Chaque app est provisionnée avec sa propre base Postgres dédiée, isolée du schéma et des données de toutes les autres apps
- pgvector est intégré pour stocker et interroger des embeddings aux côtés de vos tables relationnelles dans la même base
- TimescaleDB est intégré pour les séries temporelles, si bien que métriques et flux d'événements côtoient les tables centrales de votre app
- Tarification au stockage : vous ne payez que ce que vous stockez, ce qui garde les petites apps et les apps expérimentales bon marché
- S'inscrit dans le modèle BYOK et local-first d'osFoundry : vous fournissez les clés de modèle pour les embeddings ; la base qui les stocke est la vôtre, par app
Cas d’usage
- Créateur d'apps : livrez une app qui a besoin de tables relationnelles, de recherche sémantique et de tableaux de bord sans câbler trois services de données distincts
- Développeur IA : stockez des embeddings de documents avec pgvector et lancez une recherche par similarité dans le même Postgres qui contient les enregistrements de votre app
- Créateur solo : lancez de nombreuses petites apps, chacune avec sa propre base, et ne payez que pour la poignée qui accumule vraiment des données
Questions fréquentes
Chaque app reçoit-elle vraiment une base Postgres distincte, ou s'agit-il d'une seule instance partagée ?
Chaque app reçoit sa propre base Postgres, isolée des autres apps. Son schéma, ses index et ses données lui appartiennent, et quand vous supprimez l'app, sa base part avec elle. C'est cette isolation qui empêche les apps d'entrer en collision et les rend faciles à faire évoluer ou à démonter.
Dois-je installer pgvector et TimescaleDB moi-même ?
Non. pgvector et TimescaleDB sont intégrés à la base de chaque app. Vous pouvez stocker et interroger des embeddings et travailler avec des séries temporelles dans le même Postgres qui contient vos tables relationnelles, sans ajouter d'extensions ni de services séparés.
Comment le Postgres par app est-il facturé ?
Vous ne payez que ce que vous stockez. La facturation suit votre stockage réel, si bien qu'une app contenant peu de données coûte peu, et que les bases vides ne sont pas facturées comme si elles étaient pleines. C'est ce qui rend viable, par défaut, de donner à chaque app sa propre base.