A Cryptographically Verifiable
Database Engine for Institutions That Can't Afford to Trust Their Own Database.

pgcrypto gives you encryption functions. VectorLedger gives you a complete cryptographically verifiable ledger system. The distinction matters when an auditor asks you to prove no record was silently altered between two dates.

With pgcrypto you have encrypted columns, but no hash chain, no commit signatures, no tamper-evident audit log, no Merkle proofs, and no compliance report. You would need to build all of that yourself, correctly, on top of PostgreSQL.

VectorLedger provides all of it out of the box and still speaks the PostgreSQL wire protocol, so your existing Postgres clients connect without changes.

Every journal entry contains H(sequence || prev_hash || content_hash). If any byte of any historical entry is modified, that entry's hash changes, which invalidates every subsequent hash in the chain all the way to the present.

Running SELECT VERIFY_CHAIN() recomputes every hash in the chain and checks every Ed25519 signature. If even one byte was changed, the command reports exactly which sequence number the chain breaks at. A third party with only the public key can independently verify - without trusting the server.

When a journal entry targets an account with require_four_eyes = true, the entry is not posted immediately. It is persisted to a durable approval queue and an ApprovalId (UUID) is returned to the submitter.

A second, different principal approves the entry. The server verifies approver_id != submitter_id - this check is performed on the authenticated session identity, so it cannot be bypassed by whitespace or case tricks. Self-rejection is also blocked. On approval, the entry is posted atomically with idempotency protection against double-posting on crash recovery.

Both the original submission, the approval (or rejection), and the approver identity are permanently recorded in the WORM audit log.

VectorLedger supports three HSM backends through a unified Pkcs11Provider trait:

SoftHSM (PyHSM) - a VectorGuard Labs product. The TypeScript daemon listens on a Unix domain socket. Key material is AES-256-GCM-SIV encrypted inside PyHSM's keystore and never touches disk in plaintext. Suitable for development, CI, and production deployments without dedicated hardware.

AWS CloudHSM - via a bridge sidecar that translates VectorLedger's IPC protocol to PKCS#11 calls inside the CloudHSM cluster.

Azure Dedicated HSM - via a bridge sidecar wrapping the Thales Luna Network HSM 7 PKCS#11 library. Raw key material never leaves the hardware boundary on either cloud provider.

Model 1 - Local PyHSM (same server): PyHSM and VectorLedger run on the same host. VectorLedger connects via a Unix domain socket at /tmp/pyhsm.sock. Zero network overhead. Suitable for development, CI, and single-server production. Initialise with vledger init --key-source pyhsm.

Model 2 - Remote PyHSM (same-region, separate server): PyHSM runs on a dedicated server in the same region's private subnet. VectorLedger connects over TLS 1.3 + mTLS on port 8443. PyHSM's private key material is never accessible from the VectorLedger host. Recommended for production. Initialise with vledger init --key-source remote-pyhsm --pyhsm-endpoint https://pyhsm.internal.example.com:8443.

Both models follow the same lifecycle: VectorLedger seals the master key inside PyHSM on init, stores only an encrypted blob locally, and decrypts it via PyHSM on every start. If PyHSM is unreachable at startup, VectorLedger fails immediately - it never falls back silently to a weaker key source.

Key rotation via vledger rotate-keys is non-destructive. The HSM archives the old key version rather than destroying it, so existing ciphertext (which embeds the key version in its header) remains decryptable using the archived version.

New writes immediately use the new key version. Over time, as pages are naturally rewritten, they migrate to the new key. Every rotation emits a key_rotated event to the WORM audit log with the key ID, caller ID, and timestamp.

The compliance engine evaluates controls by inspecting live artifacts in the data directory - the audit log, WAL, page store, HSM config, and TLS certificate. Reports are generated against real filesystem state, not pre-written text.

For PCI-DSS v4 it evaluates controls covering Req 2.2, 3.4, 3.5, 4.2, 7.1, 10.2, 10.3, 10.5, and 11.5. For SOC 2 Type II it evaluates CC6.1, CC6.2, CC6.3, CC6.6, CC6.7, CC7.2, CC8.1, and A1.1.

Output is Markdown or JSON, piped to a file with --output. This evidence is a technical input to an audit - it does not by itself make an organization compliant. Organizational compliance requires additional policies, procedures, and independent auditor assessment.

VectorLedger enforces TLS 1.3 on all connections using rustls. TLS 1.2 and below are not offered. Both the native JSON server (port 5433) and the PostgreSQL wire-protocol server (port 5432) support mutual TLS (mTLS), as does the replication channel.

Self-signed certificates are generated at startup and persisted across restarts for convenience. For production, replace them with CA-signed certificates by passing --tls-cert-path and --tls-key-path at startup. The compliance engine flags self-signed certificates as a WARN finding on the relevant SOC 2 and PCI-DSS controls.

VectorLedger enforces per-listener resource controls to prevent resource exhaustion:

No. VectorLedger speaks the PostgreSQL wire protocol on port 5432. Clients point their existing PostgreSQL connection string at VectorLedger and their application works as-is - no code changes required.

Any ORM, query builder, or database driver that speaks the PostgreSQL wire protocol is immediately compatible. This includes Django, Rails, Spring, Prisma, SQLAlchemy, JDBC, and every major ORM out of the box. If psql connects, any Postgres-compatible client connects.

To enable pgwire support, start VectorLedger with the --pgwire flag:

nohup ./target/release/vledger start --max-connections 200 --pgwire &

Then connect with any standard PostgreSQL client:

psql "host=127.0.0.1 port=5432 user=admin dbname=vledger sslmode=require"

Yes. Because YugabyteDB is itself PostgreSQL wire protocol compatible, any client that talks to YugabyteDB can also talk to VectorLedger via pgwire without any driver changes.

The more compelling deployment pattern is running both systems together rather than replacing one with the other:

• YugabyteDB handles distributed, horizontally scalable OLTP - what it is built for.
• VectorLedger sits beside it as the immutable audit ledger - every financial transaction, compliance event, or sensitive write is mirrored to VectorLedger for cryptographic proof and tamper-evident history.
• The application connects to both using the same PostgreSQL driver it already uses.

This pattern is particularly strong for financial services (SOX, PCI-DSS), healthcare (HIPAA), legal (chain of custody), and supply chain (custody transfer records) - industries where keeping your operational database and adding a verifiable audit ledger is far less disruptive than replacing either system.

Generic PostgreSQL stores your data in mutable tables. Any admin, DBA, or compromised account can UPDATE or DELETE records - including audit logs. Compliance reports rest on trust that data has not been touched, and if a record is changed there is no cryptographic evidence it ever existed in a different state.

PostgreSQL + VectorLedger makes every write append-only and cryptographically chained. Each record's hash includes the previous record's hash, so any modification to history is immediately detectable. Merkle proofs let you prove to an auditor, regulator, or court that a specific record existed at a specific time and has not changed since. Compliance is based on math, not trust.

In a real scenario: a bank processes a $10M wire transfer. Six months later there is a dispute. With generic Postgres the answer to "how do you know this record hasn't been modified?" is "trust us." With VectorLedger the answer is a cryptographic Merkle proof - independently verifiable, no byte changed since the moment of writing. That answer holds up in a PCI audit, an SEC investigation, and court.

One sentence version: Postgres stores your data. VectorLedger proves your data hasn't been touched since the moment it was written.

No - only records written after the cutover date receive cryptographic guarantees. This is a well-known industry challenge called the "genesis problem": the same reason a blockchain's history is only trustworthy from block 0. You cannot add cryptographic guarantees retroactively to history that was written without them.

If you migrate existing records into VectorLedger, they are ingested and hashed from the point of migration - but the proof only guarantees the data was in a particular state at the time of ingestion, not at the time it was originally written. An auditor would rightfully ask whether the data was altered in Postgres before migration.

The recommended approach for compliance-sensitive clients:

• Day 1 forward - every new write is cryptographically verified, immutable, and provable.
• Pre-existing data - keep legacy Postgres data as-is for historical reference; the guarantee is "this is what the data looked like on migration day," not "this is what it looked like when originally written."
• Best practice - use VectorLedger as the system of record for everything from the cutover date forward.

For most compliance frameworks - SOX, PCI-DSS, HIPAA - a clean cutover date with a verified ledger from that point forward is fully acceptable.