Security
Enforced in the planner, not an application tier
Three-state privileges, row-level security, column masking, ABAC, and mandatory access control are evaluated inside query planning. The policy is part of the plan itself, so there is no application tier to bypass. Verifiable tables carry that down to the stored bytes, with one SHA-256 chain entry per commit.
Access control
Layered rules, resolved in one place
The planner resolves privileges, row filters, masks, and labels while it builds the plan. What reaches the executor is already the governed query.
Three-state privileges
Every privilege is GRANT, DENY, or unset. DENY always wins, and a column-level rule overrides the table-level rule.
Temporal grants
Grants carry validity windows, including recurring time windows, so access expires on its own schedule.
Row-level security
Policies filter tables row by row, and row ownership binds each row to an owning principal.
Attribute-based access control
ABAC rules weigh attributes of the user, the session, and the data, not just role membership.
Mandatory access control
Security labels set an access ceiling that object owners cannot waive, enforced by the engine on every access.
Data classification
Data carries classification levels, and clearance enforcement keeps under-cleared sessions away from it.
How the three states resolve
Explicitly allowed at this scope.
Explicitly blocked. DENY beats GRANT wherever the two collide.
No rule at this scope. A column without its own rule keeps the table-level outcome.
DENY always wins over GRANT, and a column-level rule overrides the table-level rule for that column. A column with no rule of its own keeps the table-level outcome.
Access control lives in the zyron-auth crate and is applied by the same planner that orders joins on the database page. There is no policy proxy in front of the engine and nothing left for a client library to enforce.
Masking
Masking that lives on the column
Column data masking controls what a query returns from a sensitive column. Seven mask types cover the usual shapes of sensitive data, from partial reveals to full hashes, and custom masks handle the rest.
Grants get the same DDL treatment. A GRANT can carry a validity window, so access to a revenue table lapses on schedule instead of waiting for a cleanup ticket.
-- Column masking as a policy
ALTER TABLE patients ADD MASKING POLICY ssn USING mask_ssn();
-- A grant with a validity window
GRANT SELECT ON revenue TO analyst
VALID FROM '2026-01-01' UNTIL '2026-12-31';Both statements run over an unchanged PostgreSQL connection.
Authentication
Identity for people, services, and platforms
Interactive logins, machine credentials, and cloud platform identities authenticate natively against the server, with throttling and session binding behind all of them.
Passwords
Stored behind a memory-hard key derivation function.
API keys
Key-based authentication for services and automation.
JWT
Signed JSON Web Tokens for token-based sessions.
TOTP
Time-based one-time passcodes as a second factor.
WebAuthn
Passkeys and hardware security keys.
OAuth2
Delegated sign-in through an identity provider.
AWS STS / Secrets Manager
Short-lived AWS credentials and managed secret retrieval.
Kubernetes
Service account identity for workloads in a cluster.
Brute-force throttling
Repeated failed attempts are slowed down, so guessing credentials at scale stops paying.
Session binding
A session can be locked to its source IP and capped with query limits.
Operational safety
Admin power, held accountable
The riskiest identity in any database is the administrator. These controls make emergency access auditable, sensitive DDL deliberate, and privilege sprawl visible.
Break-glass access
Emergency access for real incidents, with every use recorded in the audit trail.
Two-person rule
Sensitive DDL waits for a second person to approve before it takes effect.
Privilege analytics
Visibility into who holds which privileges across the whole system.
Delegation lineage
Every privilege traces back through the chain of grants that produced it.
Cascade revoke
Revoking a grant also revokes everything that was granted onward from it.
Lifecycle governance
Governed to the end of the data's life
Retention, tiering, deletion, and compliance are engine statements with the same authority as the access rules above, not cron jobs scheduled around the database.
Aging and tiering
- Retention and TTL declared on the table itself
- Tiered storage and archival to object storage
- Data-residency enforcement on tier moves
- DRY RUN previews for archive, erasure, and retention
Immutable records
- WORM and time-bounded retention locks, immutable even to admins
- Legal hold that suspends deletion while it stands
- Tamper-evident audit chain
Deletion and recovery
- Soft delete with a recycle bin and UNDROP
- GDPR erasure and DSAR export
- Crypto-shred when deletion has to be final
Compliance presets
A single compliance_profile setting applies a preset for the regulation a deployment answers to.
-- Retention on the table itself
ALTER TABLE events SET TTL '90 days';
-- Tier cold data out to object storage
ARCHIVE TABLE old_events
WHERE created < '2024-01-01' TO 's3://archive/events';Retention and archival, straight from the SQL surface.
Lifecycle enforcement ships in the zyron-lifecycle crate, one layer of the crate stack shown on the database page. Key management lands with the distribution milestone now in progress on the roadmap.
Signing keys move with the same care. Signature agility covers JWTs, X.509 certificates, and custom binary artifacts, with a current and a deprecating scheme per artifact kind and an overlap window for rotation, described on the upgrades page.
Verifiable tables
A hash chain behind every verified table
A table can be created as verified. From then on every committing transaction writes one SHA-256 chain entry over the table's stored bytes, and each entry links to the one before it, so the bytes on disk can be checked against the chain at any later point.
One entry per committing transaction, linked at apply on every consensus member in log order. VERIFY TABLE recomputes links in full or by sample, and the chain head can be anchored and exported outside the cluster.
The same chain on every member
On a consensus group the link is written at apply, on every member, in log order. Each member ends up holding the same chain rather than a copy of the leader's.
Full or sampled, cancellable
Verification walks the chain in full or checks a sample, and a running verification can be cancelled. A genesis set of sorted digests sits behind a transaction fence and fixes where the chain starts.
Anchored heads
A chain head can be anchored, and the anchor exported outside the cluster, so the reference for a later check does not live only on the nodes that wrote the chain.
The compliance log on the same chain
The compliance log is itself a verified table on the same chain, so the record of who did what carries the same tamper evidence as the data it describes.
The chain link is written by the applier that lands every committed entry on a Raft group, in log order, which is why every member holds the same chain. That applier is described on the consensus page. Commit chains and their anchors carry the versioned envelope every persistent file gets, covered on the upgrades page, and verification itself ships in the zyron-lifecycle crate beside the retention and archival controls above, one layer of the crate stack on the database page.
Running in the next five minutes
Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.