Security model
What actually protects your data
This page describes what's built and verified today, not a roadmap and not
a compliance checklist. We don't hold certifications like SOC 2 or HIPAA
today — if that's a hard requirement, tell us on the
contact form and we'll be straight with you about
timeline.
01
Namespace isolation, enforced server-side
Every application or tenant on a BiseraDB instance is assigned a
namespace. Queries and writes are validated against the caller's API
key on every request — a tenant-scoped key can only see its own
namespace, and the check happens inside the engine itself, not as an
optional filter the calling application has to remember to add.
- Enforced on every query, not just at write time
- A tenant key literally cannot address another namespace's data
- Admin keys are separate, more privileged, and used only for platform operations
02
Scoped, revocable API keys
Keys are issued with an explicit scope — admin or tenant — and a
tenant key is bound to specific namespaces at creation time. Any key
can be revoked immediately without affecting others.
03
Durability by design
Every write goes through a write-ahead log before it's acknowledged.
Checkpointing and archive rotation keep recovery bounded, and startup
recovery replays anything that wasn't checkpointed after an
unexpected restart.
04
Encrypted in transit
Every admin surface — the API, the operator console, this site —
runs behind TLS with real, automatically-renewing certificates.
There's no unencrypted path to any administrative interface.
05
Not multi-tenant SaaS
Onshore Systems deploys and operates BiseraDB in-house for each
client rather than co-locating your data with other customers on
shared cloud infrastructure. Your instance, your namespace
boundaries, operated by us.
06
Verified migrations, not assumed ones
When data moves into BiseraDB from an existing database, the
migration engine reconciles every row between source and target
before a job is marked complete — a direct comparison, not just a
row-count match.
