osFoundry / Platform
Postgres per app
Ogni app ottiene il proprio Postgres con pgvector e TimescaleDB. Paghi solo quello che archivi.
Che cos’è
Postgres per app dà a ogni applicazione che costruisci in osFoundry un proprio database Postgres dedicato, invece di costringere tutte le app a condividere un solo schema o una sola connessione. Ogni database arriva con pgvector per archiviare e interrogare embedding e con TimescaleDB per i dati di serie temporali, così un unico database può contenere le tue tabelle relazionali, i vettori per la ricerca semantica e le tue metriche o flussi di eventi senza dover innestare servizi separati. Le chiavi dei modelli che generano quegli embedding le porti tu; il Postgres che li archivia viene fornito per singola app.
Poiché ogni app è isolata nel proprio database, lo schema, gli indici e i dati di un'app non possono collidere con quelli di un'altra. Questo isolamento rende le app più facili da ragionare, più sicure da iterare e più pulite da smantellare: quando un'app scompare, il suo database se ne va con lei. All'interno di osFoundry questo vive nel livello Apps e Backend, così l'app che costruisci ottiene un vero datastore di backend anziché un archivio chiave-valore giocattolo, e lo stesso database è disponibile per il codice lato server dell'app, per la sua ricerca vettoriale e per le sue query di serie temporali. osFoundry è uno spazio di lavoro BYOK e local-first, quindi anche questo segue il principio che attraversa tutto il prodotto: i tuoi dati e l'infrastruttura su cui risiedono restano tuoi, e non ci sono tariffe per postazione sovrapposte.
Il prezzo segue ciò che usi davvero. Paghi solo ciò che archivi, così un'app che contiene qualche migliaio di righe costa di conseguenza, e un'app che non riempie mai il suo database non viene fatturata come se lo facesse. Questo rende pratico dare a ogni app il proprio Postgres per impostazione predefinita, anche a quelle piccole o sperimentali, invece di razionare i database per risparmiare. pgvector e TimescaleDB fanno parte del database che hai già, non sono add-on con una voce di fatturazione a parte.
Funzionalità principali
- Ogni app viene fornita con il proprio database Postgres dedicato, isolato dallo schema e dai dati di ogni altra app
- pgvector è integrato per archiviare e interrogare embedding accanto alle tue tabelle relazionali nello stesso database
- TimescaleDB è integrato per le serie temporali, così metriche e flussi di eventi stanno accanto alle tabelle centrali della tua app
- Prezzo basato sull'archiviazione: paghi solo ciò che archivi, così le app piccole e sperimentali restano economiche
- Si allinea al modello BYOK e local-first di osFoundry: fornisci tu le chiavi dei modelli per gli embedding; il database che li archivia è tuo, per singola app
Casi d’uso
- Creatore di app: pubblica un'app che ha bisogno di tabelle relazionali, ricerca semantica e dashboard senza cablare tre servizi dati separati
- Sviluppatore IA: archivia gli embedding dei documenti con pgvector ed esegui la ricerca per similarità nello stesso Postgres che contiene i record della tua app
- Maker solitario: avvia tante piccole app, ognuna con il proprio database, e paga solo per quella manciata che accumula davvero dati
Domande frequenti
Ogni app riceve davvero un database Postgres separato, o è un'unica istanza condivisa?
Ogni app riceve il proprio database Postgres, isolato dalle altre. Il suo schema, i suoi indici e i suoi dati sono suoi, e quando rimuovi l'app il suo database se ne va con lei. È questo isolamento che impedisce alle app di collidere e le rende facili da iterare o smantellare.
Devo installare io pgvector e TimescaleDB?
No. pgvector e TimescaleDB sono integrati nel database di ogni app. Puoi archiviare e interrogare embedding e lavorare con serie temporali nello stesso Postgres che contiene le tue tabelle relazionali, senza aggiungere estensioni o servizi separati.
Come viene tariffato il Postgres per app?
Paghi solo ciò che archivi. La fatturazione segue l'archiviazione effettiva, così un'app con pochi dati costa poco e i database vuoti non vengono fatturati come se fossero pieni. È questo che rende pratico, per impostazione predefinita, dare a ogni app il proprio database.