Database Management (Strix)

What this is

Axowl’s integrity guarantee has one hard requirement: a record can only be sealed if it enters through a write path Axowl controls. Database Management is how application data — not just identity events — gets that guarantee. It comes in two models, chosen by plan:

Strix — sealed Postgres (Free / Pro / Business) — Axowl provisions the database: plain PostgreSQL, standard SQL reads, every driver and BI tool you already use. Your app writes through the SDK or API; there is no raw write connection to bypass. Every record is sealed from its first write, and because the data lives in the plane Axowl operates, the full analytics surface (funnels, retention, behavioral queries) works out of the box.
Key-loan (Enterprise) — the data stays in your instance, in your network, under your compliance regime. Axowl never sees the contents: on every write your side sends a hash, Axowl signs it with a key you never hold, timestamps it, and anchors it append-only. Nobody — including the database owner — can silently rewrite history, because re-sealing produces a new sequence position and that is the detection. See Seals & integrity.

Authentication analytics (logins, sign-ups, MAU) work on every plan regardless of model, because Axowl is the identity provider either way.

The write-path principle

Integrity does not come from owning the database. It comes from two things:

Write-path exclusivity — the only writer to a sealed table is the sealed service.
Key custody — the sealing key is never in the hands of whoever holds the data.

This is why the managed plane accepts no raw write connections (a read-only replica endpoint is available on request), and why key-loan works even though Enterprise data never leaves the customer’s network. The two models are the same principle applied from opposite ends.

Two starting points

New project? There is no ladder for you — create an app group and Strix is attached. Write your first record through the SDK and it is sealed, as is everything after it. Nothing to migrate, nothing to configure.
Existing database? You climb the ladder below, one rung at a time, and migration is the last step — taken only if and when you choose it.

Regions

Every organization declares a home region when it is created — it appears as the badge in the console header, and everything you create afterward follows it by default. When you create a Strix database you can keep the organization default or pick a different data region per app group; the region you choose is where that database physically lives.

Region codes are Axowl’s own (kr, sg, au, eu-de, uk, us-e) and stay stable even as the underlying infrastructure evolves — the code you picked at creation never changes meaning underneath you. Each database records both its Axowl region and the physical provider region it was provisioned in at creation time, so residency answers come from the record, not from today’s mapping.

One honest note on residency: the Asia-Pacific data plane currently runs from Singapore, so kr data is near Korea, not inside it. If your compliance requires data on soil you control, that is the Enterprise isolated-instance track — not a region choice.

The adoption ladder (existing databases)

Nobody migrates a production database on day one, so Database Management is built as a ladder — every rung pays for itself, and no rung requires the next:

Rung	What it does	Status
Connect	Register the database you already run, read-only. Powers the admin console and integrity coverage reporting.	✅ Built
Gated writes	Writes that go through Axowl pass the approval gate and come out stamped. Your database, our receipts.	✅ Built (single-row, guarded)
Witness	Detect changes made around Axowl. Default path: your app emits change events through the SDK — no agent, nothing installed, zero contact with your database. Enterprise path: an agent runs inside your network, consumes the change stream locally, and sends only hashes outbound.	🚧 Design
New data starts sealed	New tables and features land on the managed plane; existing data stays where it is.	🚧 Design
Full migration	The migration wizard moves the rest — and seals a genesis marker into the chain: records before the import point are declared external history, not covered; everything after is sealed for life. The chain never claims more than it can prove.	🚧 Design

Migration tooling is free on every plan.

What Axowl will not do to your database

These are commitments, not caveats — the design was audited against a “zero customer-database risk” bar:

No live analytics queries against your primary. Dashboard analytics are served from low-frequency snapshots cached on Axowl’s side. Real-time direct queries are only enabled when you connect a read replica.
No broad credentials. The connection wizard generates a role-creation script scoped to the tables and columns you choose, with statement_timeout and a connection limit built in. Wide-privilege accounts are rejected at registration.
No replication slots owned from outside your network. The witness agent (Enterprise) refuses to install unless PostgreSQL 13+ with max_slot_wal_keep_size configured — the failure mode where an abandoned slot fills your disk is excluded by precondition, not by promise. If the witness is ever interrupted, the gap itself is sealed as an explicit event rather than papered over.
No dual-writes, ever. A product whose ledger is the truth cannot run a migration mode where the truth exists in two places.
Contents stay yours. Coverage reporting reads hashes and row counts, not values. Where personal data is read at all (snapshot analytics), it is covered by a data-processing agreement.

Pricing shape

Strix has no free tier — it starts as a low-cost paid add-on with a card on file, and paid plans include a storage allowance. The plan opens the gate and usage pays: managed storage is metered past the included volume, witness events meter past the included million, and migration tooling is free on every plan. The pricing page is the live schedule; constants in PricingConstants.Strix win over any prose.

API — data source connections (✅ built)

Base: /api/org/{slug}/app-groups/{groupId}/data-sources (authenticated; the organization must own the app group).

Method · Route	Purpose
GET `/`	List connections — passwords are never returned, only `hasPassword`. The primary source sorts first.
POST `/test`	Test a connection before saving it
POST `/`	Register (accepts a full connection string or individual fields; a failed test still registers, recorded as unreachable)
POST `/{id}/test`	Re-test with stored credentials — audited as its own event, since it exercises the stored password
POST `/strix`	Create a managed Strix database (requires the Strix integration to be active). Body: `{ name, region? }` — region falls back to the organization’s home region. Returns the connection registered as `IsManaged`, sealed from the first row
POST `/{id}/primary`	Mark the source the console and admin boards read from (one per group; added 2026-08-04)
DELETE `/{id}`	Disconnect — the row is kept; when it was connected and disconnected is part of the record

Every mutation publishes a sealed audit event (appgroup.datasource.connected / disconnected / tested / primary_changed). Credentials never appear in events.

Seals & integrity — how sealing and verification work
Organizations & members — where app groups sit
Audit API — querying sealed events