osFoundry / Platform
Per-app Postgres
Every app gets its own Postgres with pgvector and TimescaleDB. Pay only for what you store.
What it is
Per-app Postgres gives each app you build in osFoundry its own dedicated Postgres database, rather than forcing every app to share one schema or one connection. Each database ships with pgvector for storing and querying embeddings and TimescaleDB for time-series data, so a single database can hold your relational tables, your semantic-search vectors, and your metrics or event streams without bolting on separate services. You bring your own model keys for anything that generates those embeddings; the Postgres that stores them is provisioned per app.
Because each app is isolated to its own database, one app's schema, indexes, and data can't collide with another's. That isolation makes apps easier to reason about, safer to iterate on, and cleaner to tear down: when an app goes away, its database goes with it. Inside osFoundry this sits in the Apps & Backend layer, so an app you build gets a real backend datastore instead of a toy key-value store, and the same database is available to the app's server-side code, its vector search, and its time-series queries. osFoundry is a bring-your-own-key, local-first workspace, so this fits the same principle that runs through the product: your data and the infrastructure it lives on stay yours, and there are no per-seat fees layered on top.
Pricing follows what you actually use. You pay only for what you store, so an app that holds a few thousand rows costs accordingly, and an app that never fills its database doesn't get billed as if it did. That makes it practical to give every app its own Postgres by default, even small or experimental ones, instead of rationing databases to save money. pgvector and TimescaleDB are part of the database you already have, not add-ons with separate line items.
Key capabilities
- Every app is provisioned with its own dedicated Postgres database, isolated from every other app's schema and data
- pgvector is built in for storing and querying embeddings alongside your relational tables in the same database
- TimescaleDB is built in for time-series data, so metrics and event streams live next to your app's core tables
- Storage-based pricing: you pay only for what you store, so small and experimental apps stay cheap
- Fits osFoundry's BYOK, local-first model: you supply model keys for embeddings; the database that stores them is yours per app
Use cases
- App builder: Ship an app that needs relational tables, semantic search, and dashboards without wiring up three separate data services
- AI developer: Store document embeddings with pgvector and run similarity search in the same Postgres that holds your app's records
- Solo maker: Spin up many small apps, each with its own database, and only pay for the handful that actually accumulate data
Frequently asked questions
Does each app really get a separate Postgres database, or is it one shared instance?
Each app gets its own Postgres database, isolated from other apps. Its schema, indexes, and data are its own, and when you remove the app, its database goes with it. That isolation is what keeps apps from colliding and makes them easy to iterate on or tear down.
Do I need to install pgvector and TimescaleDB myself?
No. pgvector and TimescaleDB come built into each app's database. You can store and query embeddings and work with time-series data in the same Postgres that holds your relational tables, without adding separate extensions or services.
How is per-app Postgres priced?
You pay only for what you store. Billing follows your actual storage, so an app holding little data costs little, and empty databases don't get billed as if they were full. That's what makes giving every app its own database practical by default.