If you are deciding
When your board asks where applicant records are held and who changed them, there is a direct answer to both.
If you use it daily
Nothing changes in how you work. Every change you make is recorded against your name without you doing anything.
If you are doing diligence
Database per tenant, optional customer-hosted; prefix-enforced file storage; authorize, write and audit in one transaction. Control plane on StreamBuild in Canada.
A separate database per agency
Each agency has its own Postgres database, rather than a shared set of tables with an agency column and a filter over them. There is no agency identifier in the tenant schema, because there is nothing else in that database for it to distinguish between.
Your database, in your account
An agency can host its tenant database in its own cloud account. This is in production today: an agency running live programs on StreamBuild keeps its tenant database in its own Neon project, while the application runs on StreamBuild’s infrastructure. It is available to any tenant.
File storage is isolated by prefix
Every agency’s files are stored under its own prefix. The storage layer refuses any key outside the agency’s prefix before the request reaches the storage driver, so a mistake elsewhere in the code cannot read or write another agency’s files.
One write path
Every change, in one transaction
- 1
Authorize
Is this person allowed to make this change to this record?
- 2
Write
The change itself.
- 3
Audit
A row recording who made the change, to what, and when.
All three happen inside one database transaction. If the audit row cannot be written, the change is rolled back with it. So the audit trail cannot drift from the data for anything changed through StreamBuild: a change that failed to record itself did not happen either.
Today the audit log is surfaced as the activity feed on each record. An engagement or an organization shows its own history. There is no standalone audit viewer and no audit export.
What stays on StreamBuild’s infrastructure
In your tenant database
- Organizations, contacts and engagements
- Notes, deliverables and their assumptions
- Workflows and tasks
- Budgets, expenses and claims
- The audit log of changes to all of the above
On StreamBuild, in Canada
- Users, memberships and roles
- AI usage records
- Billing
- Uploaded files, in a per-agency bucket
- The application itself
So the accurate claim is that your program records live in your database, in your region, under your account. It is not that none of your data touches our infrastructure. The control plane and your files do. StreamBuild’s infrastructure is in Canada, in Toronto (northamerica-northeast2).
- Region
- Canada. Toronto, northamerica-northeast2.
- Privacy
- Designed against PIPEDA. This is our own assessment, not a certification.
- SOC 2
- Not held. On the roadmap.
What this does not do
- The control plane, covering users, memberships, roles, AI usage and billing, is on StreamBuild’s infrastructure, not in your database.
- Uploaded files are stored in a per-agency bucket on StreamBuild’s infrastructure, even when your database is in your own account.
- AI inference leaves Canada today: the default model provider is US-hosted. Your database, files and backups do not. A Canadian inference option is on our roadmap for October 2026. See Governed AI.
- There is no standalone audit trail viewer and no audit export.
- The audit guarantee covers changes made through StreamBuild. Changes made directly to a database you host yourself are outside it.
- StreamBuild is not SOC 2 certified.