osFoundry / Platform
Postgres por app
Cada app obtiene su propio Postgres con pgvector y TimescaleDB. Paga solo por lo que almacenes.
Qué es
Postgres por app le da a cada aplicación que construyes en osFoundry su propia base de datos Postgres dedicada, en lugar de obligar a todas las apps a compartir un mismo esquema o una única conexión. Cada base de datos incluye pgvector para almacenar y consultar embeddings, y TimescaleDB para datos de series temporales, de modo que una sola base de datos puede contener tus tablas relacionales, los vectores de búsqueda semántica y tus métricas o flujos de eventos sin tener que añadir servicios aparte. Tú aportas tus propias claves de modelo para todo lo que genere esos embeddings; el Postgres que los almacena se aprovisiona por app.
Como cada app queda aislada en su propia base de datos, el esquema, los índices y los datos de una app no pueden colisionar con los de otra. Ese aislamiento hace que las apps sean más fáciles de razonar, más seguras de iterar y más limpias de desmontar: cuando una app desaparece, su base de datos se va con ella. Dentro de osFoundry esto vive en la capa de Apps y Backend, así que la app que construyes obtiene un almacén de datos real como backend en lugar de un almacén clave-valor de juguete, y esa misma base de datos está disponible para el código de servidor de la app, para su búsqueda vectorial y para sus consultas de series temporales. osFoundry es un espacio de trabajo BYOK y local-first, así que esto encaja con el mismo principio que atraviesa todo el producto: tus datos y la infraestructura donde viven siguen siendo tuyos, y no hay tarifas por asiento apiladas encima.
El precio sigue lo que realmente usas. Pagas solo por lo que almacenas, así que una app que guarda unos pocos miles de filas cuesta en consecuencia, y una app que nunca llena su base de datos no se factura como si lo hiciera. Eso hace práctico darle a cada app su propio Postgres por defecto, incluso a las pequeñas o experimentales, en vez de racionar bases de datos para ahorrar. pgvector y TimescaleDB forman parte de la base de datos que ya tienes, no son extras con una línea de factura aparte.
Capacidades principales
- Cada app se aprovisiona con su propia base de datos Postgres dedicada, aislada del esquema y los datos de las demás apps
- pgvector viene integrado para almacenar y consultar embeddings junto a tus tablas relacionales en la misma base de datos
- TimescaleDB viene integrado para series temporales, de modo que métricas y flujos de eventos conviven con las tablas centrales de tu app
- Precio por almacenamiento: pagas solo por lo que guardas, así que las apps pequeñas y experimentales salen baratas
- Encaja con el modelo BYOK y local-first de osFoundry: tú aportas las claves de modelo para los embeddings; la base de datos que los guarda es tuya por app
Casos de uso
- Constructor de apps: publica una app que necesita tablas relacionales, búsqueda semántica y paneles sin cablear tres servicios de datos distintos
- Desarrollador de IA: guarda embeddings de documentos con pgvector y ejecuta búsqueda por similitud en el mismo Postgres que contiene los registros de tu app
- Creador en solitario: levanta muchas apps pequeñas, cada una con su propia base de datos, y paga solo por el puñado que de verdad acumula datos
Preguntas frecuentes
¿Cada app recibe de verdad una base de datos Postgres separada, o es una única instancia compartida?
Cada app recibe su propia base de datos Postgres, aislada de las demás. Su esquema, sus índices y sus datos son suyos, y cuando eliminas la app su base de datos se va con ella. Ese aislamiento es lo que evita que las apps colisionen y hace que sea fácil iterarlas o desmontarlas.
¿Tengo que instalar pgvector y TimescaleDB por mi cuenta?
No. pgvector y TimescaleDB vienen integrados en la base de datos de cada app. Puedes almacenar y consultar embeddings y trabajar con series temporales en el mismo Postgres que contiene tus tablas relacionales, sin añadir extensiones ni servicios aparte.
¿Cómo se cobra el Postgres por app?
Pagas solo por lo que almacenas. La facturación sigue tu almacenamiento real, así que una app con pocos datos cuesta poco y las bases de datos vacías no se cobran como si estuvieran llenas. Eso es lo que hace práctico, por defecto, darle a cada app su propia base de datos.