Why Your Compliance Team Secretly Wants Sentinel: The Database That Audits Itself

The Compliance Nightmare You Didn’t Know You Had

Your compliance officer just asked a simple question: “Can you prove that file X hasn’t been modified in the last six months?”

What should be a five-minute answer turns into a five-day investigation. You dig through backup logs, check database transaction histories, search for audit entries, and cross-reference three different systems. The answer was probably always yes, but proving it cost you 40 hours of engineering time.

This is the compliance theater most organizations live in. Databases store data one way, audit systems track changes another way, and nobody really knows if they’re synchronized. When an auditor asks for evidence, you’re scrambling to reconstruct the truth from partial logs scattered across multiple systems.

There’s a better way.

Sentinel reimagines the entire problem. Instead of bolting audit trails onto a database that wasn’t designed for compliance, Sentinel makes auditability the core architecture. Every document is a file. Every change is visible. Every piece of data can be verified with cryptography. No special tools. No smoke and mirrors. Just your data, auditable from day one.

The Simple Idea That Changes Everything

Sentinel’s core principle sounds almost too simple: the filesystem IS the database. Your data lives as JSON files on disk. Collections are folders. Documents are individual files with their filenames as primary keys.

This sounds primitive until you realize something profound: the filesystem is already solving problems you’re paying for databases to solve. File permissions exist. Git versioning exists. Backups exist. Encryption exists. Cryptographic hashing exists.

Why are you paying database vendors to rebuild all of this in proprietary formats?

Let’s look at a concrete example:

1
use sentinel_dbms::{Store, SentinelError};
2
use serde_json::json;
3

4
#[tokio::main]
5
async fn main() -> Result<(), SentinelError> {
6
    // Create a store with encryption
7
    let store = Store::new("./sentinel-db", Some("secret_passphrase")).await?;
8

9
    // Get a collection (creates directory if needed)
10
    let users = store.collection("users").await?;
11

12
    // Insert a document (creates JSON file with hash & signature)
13
    users.insert("user-123", json!({
14
        "name": "Alice",
15
        "email": "[email protected]",
16
        "role": "admin"
17
    })).await?;
18

19
    // Retrieve the document
20
    let doc = users.get("user-123").await?;
21
    println!("Found: {:?}", doc);
22

23
    Ok(())
24
}

When you insert that document, Sentinel creates a file that looks like this:

1
{
2
  "id": "user-123",
3
  "version": 1,
4
  "created_at": "2026-01-15T12:00:00Z",
5
  "updated_at": "2026-01-15T12:00:00Z",
6
  "hash": "a1b2c3d4e5f6...",
7
  "signature": "ed25519:...",
8
  "data": {
9
    "name": "Alice",
10
    "email": "[email protected]",
11
    "role": "admin"
12
  }
13
}

Pretty-printed. Inspectable. No binary blobs. No proprietary encoding. Run cat, grep, diff, or git log on it, whatever you want.

Now your compliance officer asks: “Prove file X hasn’t been modified.”

You run:

1
git log --oneline ./sentinel-db/data/users/user-123.json

There’s your audit trail. Dates, authors, commit hashes. Cryptographically immutable. No database queries. No special tools. Just Git, which your organization already has.

Why Traditional Databases Lost the Compliance Game

Let’s be honest: modern databases weren’t designed for compliance. They were designed for performance.

A typical PostgreSQL or MongoDB setup gives you:

• Speed: Optimized queries across millions of records
• ACID guarantees: Data consistency
• Complex indexes: Finding data quickly
• Audit logging: As an afterthought

Audit logging in traditional databases is bolted on. You enable WAL (Write-Ahead Logging), capture transaction logs, maybe ship them to a separate system, and hope nothing breaks in the pipeline. If it does, your audit trail is incomplete and nobody knows.

Meanwhile, your compliance framework demands:

• GDPR: Right-to-delete must be immediate and verifiable
• SOC 2: Complete audit trails with no gaps
• HIPAA: Encryption, access logs, and forensic readiness
• PCI-DSS: Immutable evidence of who accessed what and when

Traditional databases make these requirements hard. Sentinel makes them trivial.

The Compliance Superpowers Sentinel Unlocks

1. Native Auditability (Git Is Your Audit Engine)

Want to know every change to a user’s record? Run:

1
git log -p users/user-123.json

Full history. Commit by commit. Who changed it, when, and what the change was. No query language needed. No audit table to configure. No log aggregation pipeline. Just Git.

2. GDPR Right-to-Delete Is Literally rm

GDPR requires you to delete customer data when they request it. You also need to prove it’s deleted.

1
rm data/users/john-doe.json
2
git add -A
3
git commit -m "GDPR right-to-delete: john-doe removed on 2026-01-15"

That’s it. The user’s data is deleted. The deletion is logged in Git. The record is forensic evidence that deletion happened. Compliance auditor checks passed.

In traditional databases, you’re wrestling with foreign keys, cascading deletes, and wondering if any data leaked into backups. With Sentinel, deletion is file deletion, and Git proves it happened.

3. Encryption That Doesn’t Sacrifice Visibility

Sentinel supports multiple encryption algorithms:

• AES-256-GCM: Industry standard for data at rest
• XChaCha20-Poly1305: Modern alternative, resistant to nonce reuse
• Ascon-128: Lightweight, hardware-friendly

All optional. All transparent. Your JSON files are encrypted on disk, but Sentinel handles decryption automatically. If you need to backup unencrypted data to a secure location, just copy the files. They’re JSON. No special export tools needed.

4. Zero Lock-In

Your data is JSON files. Not Oracle’s proprietary format. Not MongoDB’s BSON if you don’t want it. Not trapped in a vendor’s ecosystem.

Need to migrate to PostgreSQL? Export to CSV:

1
for file in data/users/*.json; do
2
  jq -r '.data | @csv' "$file"
3
done > users.csv

Need to move to DuckDB? Same thing. Need to migrate to a different tool entirely in five years? Your data is waiting for you in plain text.

5. Compliance-Ready by Design

Here’s what Sentinel gives you out of the box for each major compliance framework:

Where Sentinel Shines (And Where It Doesn’t)

Sentinel isn’t a replacement for PostgreSQL. It’s a replacement for compliance theater.

Sentinel Excels At:

• Audit logs: Every entry is a file, versioned with Git
• Certificate management: Secure, inspectable, with OS-level ACLs
• Compliance rules & policies: Configuration files stored as JSON
• Encryption key management: Keys stored as files with filesystem security
• Regulatory reporting: All data is immediately forensic-friendly
• Edge devices & disconnected systems: No server required, works with Git sync
• Zero-trust infrastructure: Inspect everything before trusting it

Sentinel Struggles With:

• High-throughput operational data: Not designed for 100K+ operations per second
• Complex analytical queries: If you need to scan billions of rows, traditional databases are faster
• Massive single collections: Performance degrades around 4M files in a single folder (due to filesystem limits), though sharding collections into subfolders mitigates this

The key insight: Sentinel is not trying to replace PostgreSQL for your application database. It’s replacing all the compliance infrastructure you bolted onto PostgreSQL.

A Real-World Scenario: Certificate Management

Let’s say you manage SSL/TLS certificates for 50 servers. Compliance requires you to prove:

• When each certificate was created
• Who created it
• When it expires
• Who has access to each certificate’s private key
• Every time someone accessed or modified a certificate
• Evidence of proper deletion when certificates expire

Traditional approach:

1. Store certificates in a database
2. Set up a separate audit logging system
3. Configure file permissions on the servers
4. Ship logs to a SIEM
5. Hope all the pieces sync correctly
6. Spend two days digging through logs during an audit

Sentinel approach:

1
certs/
2
├── example.com.json
3
├── api.example.com.json
4
├── cdn.example.com.json
5
└── ...

Each file contains:

1
{
2
  "id": "example.com",
3
  "version": 3,
4
  "created_at": "2025-06-01T10:00:00Z",
5
  "updated_at": "2026-01-15T14:30:00Z",
6
  "hash": "blake3:...",
7
  "signature": "ed25519:...",
8
  "data": {
9
    "domain": "example.com",
10
    "certificate": "-----BEGIN CERTIFICATE-----\n...",
11
    "private_key": "-----BEGIN PRIVATE KEY-----\n...",
12
    "expires_at": "2027-06-01T10:00:00Z",
13
    "created_by": "devops-team",
14
    "last_modified_by": "security-engineer"
15
  }
16
}

Now run:

1
# See every certificate's full history
2
git log --oneline certs/
3

4
# Find all certificates expiring in the next 30 days
5
jq -r 'select(.data.expires_at < "2026-02-15") | .id' certs/*.json
6

7
# Prove certificate X was accessed by user Y on date Z
8
git log --all --grep="certs/example.com.json" --oneline
9

10
# Delete expired certificates with full audit trail
11
rm certs/expired-*.json
12
git add -A
13
git commit -m "Expired certificates deleted per compliance policy"

No special tools. No audit system to debug. No missing entries. No wondering if your logs are complete. Git is your audit engine.

Building Sentinel Into Your Stack

Sentinel is designed to live alongside your existing infrastructure, not replace it. Here’s how organizations typically deploy it:

Single Machine Deployment

Perfect for smaller organizations or edge locations:

1
# Initialize store
2
sentinel init --path /var/cyberpath
3

4
# Run server
5
sentinel serve --path /var/cyberpath --port 2055

Your data lives on disk. Backup via rsync. Replicate via git push.

Replicated Cluster (Git-Backed)

For organizations needing geographic redundancy:

1
# Primary node
2
git init --bare /data/cyberpath.git
3
sentinel serve --path /data/cyberpath --git-push origin main
4

5
# Secondary node
6
git clone /data/cyberpath.git /data/cyberpath
7
sentinel serve --path /data/cyberpath --git-pull origin main

Changes on the primary automatically sync to secondaries via Git. No database replication protocol. No quorum consensus. Just Git doing what it does best.

The Philosophy Behind Sentinel

Sentinel is built on a radical idea: compliance shouldn’t require special infrastructure. It shouldn’t require proprietary tools, expensive databases, or consulting firms to implement.

Your data should be inspectable. Your audit trails should be complete. Your access controls should be native to your operating system. Your backups should be standard formats. Your compliance evidence should be obvious, not hidden.

This is what Sentinel delivers. Not a faster database. Not a more feature-rich DBMS. Just a database built the way databases should have been built from the start if compliance mattered.

Getting Started with Sentinel

Ready to replace compliance theater with actual compliance?

Sentinel is open-source, production-ready, and available on crates.io; join the community on GitHub to further speed up the development and get support:

1
cargo add sentinel-dbms

Or install the CLI:

1
cargo install sentinel-cli

Documentation is at sentinel.cyberpath-hq.com. Community discussions happen on GitHub.

The question isn’t whether you need audit trails. You do. The question is whether you’ll keep bolting them onto systems that weren’t designed for compliance, or whether you’ll move to a database that was.

Sentinel is the latter.

Quick Reference: Sentinel Capabilities

Want to see Sentinel in action? Visit sentinel.cyberpath-hq.com to explore documentation, examples, and deployment guides. The GitHub repository is at github.com/cyberpath-HQ/sentinel.