The storage engine purpose-built for fiscal evidence.

Fiscal storage, finally a first-class engine.

FiscalDB is an append-only, cryptographically sealed database purpose-built for invoices. Qualified RFC 3161 timestamps on every document. Native connectors to tax authorities. PostgreSQL and MySQL wire-compatible — your drivers don't change.

Designed from the storage layer up for jurisdictions where invoices are legal evidence — not just application data.

Book a technical demo Read the architecture
postgres :5432mysql :3306rest :8080append-only WALAES-256-GCM
per-tenant hash chain sealed
LSN
41

sha256:3f9a1c8e…

tsa 0x4b8e21 · MX · SAT

LSN
42

sha256:a7d20b54…

tsa 0x4b8e22 · ES · AEAT

LSN
43

sha256:e1c6f093…

tsa 0x4b8e23 · EU · Peppol

LSN
44

sha256:0b8d47a2…

tsa 0x4b8e24 · MX · SAT

prev_hash → final_hash · RFC 3161 TimeStampToken persisted as TsaTimestampReceived

Not every database can stand in court.

General-purpose databases store invoices. FiscalDB preserves evidence.

Why FiscalDB exists

Postgres is great. It is not fiscal storage.

General-purpose databases were never designed to store fiscal evidence with legal validity. Postgres is excellent application storage — rows are mutable, audit is bolted on, there is no native hash chain, no qualified timestamp, no SAT/AEAT/Peppol connector. FiscalDB makes regulatory immutability a storage-layer guarantee, not an application-layer assumption.

PostgreSQL

optimized for

  • General applications
  • OLTP throughput
  • Schema flexibility

FiscalDB

optimized for

  • Legal evidence
  • Fiscal regulations
  • Government connectors
  • Cryptographic integrity
Requirement
Postgres
FiscalDB
Append-only at storage layer
Per-document SHA-256 hash chain
RFC 3161 qualified timestamp / document
Legal probative value (eIDAS / AEAT / SAT)
Fiscal types (TaxId, FiscalFolio, …)
Native SAT (CFDI 4.0 / PAC) connector
Native AEAT (Facturae / VeriFactu)
Native Peppol (UBL 2.1 / CTC)
Multi-tenant isolation at WAL level
PostgreSQL wire protocol
MySQL wire protocol
A new category

FiscalDB introduces a new category of storage engines.

The closest existing product is Amazon QLDB — proprietary and AWS-only. FiscalDB is also proprietary, but multi-jurisdiction, deployable on your own infrastructure or as a managed cloud, and wire-compatible with PostgreSQL and MySQL so adoption requires no driver migration.

Product
Purpose
PostgreSQL
General-purpose relational database
Amazon QLDB
Immutable ledger
FiscalDB
Fiscal evidence storage engine
Architecture

From your ERP to immutable evidence.

One path, every guarantee applied in a single append. The document your application writes becomes legally probative evidence before it ever leaves the storage layer — sealed, chained, timestamped and reported to the authority that matters.

ERP / billing system

your application

FiscalDB

drop-in storage engine

Append-only WAL

no UPDATE · no DELETE

SHA-256 hash chain

per-tenant, tamper-evident

RFC 3161 timestamp

qualified TSA token

Tax authority

SAT · AEAT · Peppol

Immutable evidence

legal probative value

The engine

An append-only, cryptographically sealed core.

Performance and integrity are the headline, not features. Everything else is built on top of an append-only, cryptographically sealed storage core.

Append-only WAL + segment storage

  • Crash recovery, magic header, CRC-32 per record.
  • zstd / lz4 compression on repetitive XML.
  • AES-256-GCM at rest (key from FISCALDB_STORAGE_KEY).

Per-tenant SHA-256 hash chain

  • Every document carries previous_hash + final_hash.
  • Replayed on recovery; tampering is detected by fiscaldb verify-chain.

RFC 3161 qualified timestamping

  • Async TSA call after every Validated event.
  • Raw DER TimeStampToken persisted as TsaTimestampReceived.
  • FNMT-RCM, DigiCert, Camerfirma, FreeTSA (test).
  • Legally valid under eIDAS Reg. 910/2014 Art. 41.
Evidence

The differentiator is legal probative value.

Every document is RFC 3161 sealed and independently verifiable against the TSA's certificate chain — even if FiscalDB is offline. This is the part that actually decides an audit, so it sits at the centre, not the footnotes.

Tax authorities

Every document is RFC 3161 sealed; the token is independently verifiable against the TSA's certificate chain even if FiscalDB is offline.

Auditors

fiscaldb verify-chain replays the per-tenant hash chain; tampering is detected at the byte level.

CISOs

AES-256-GCM at rest, mTLS to all authorities (TLS 1.2 min, rustls, no OpenSSL), HMAC-SHA256 signed webhooks, JWT + RBAC.
How it holds in court
Built for throughput

10k+/s — compared to assembling it by hand.

The benchmark that matters is not raw rows per second, it is everything a real audit trail requires, done in one operation instead of five.

Without FiscalDB

The audit trail is assembled by hand across five systems — five chances to drift, fail or be tampered with.

  • 1App writes row to general-purpose DB
  • 2Separate audit table / trigger
  • 3External timestamping service call
  • 4Application-side hash computation
  • 5Bespoke connector to tax authority

With FiscalDB

Storage, hash chain, qualified timestamp and connector are one atomic, append-only operation.

1Single append — sealed, timestamped, evidence-grade

10k+/s ingest · <1ms append · 0 LOC of audit code

10k+/s

Invoices/sec ingest on commodity hardware (zstd compressed)

<1ms

Append latency at the WAL layer

60–80%

On-disk size reduction vs raw XML in Postgres BLOB

0 LOC

Application-side code for a full TSA-sealed audit trail

Connectors

One engine. Every tax authority that matters.

Submit a draft, FiscalDB negotiates with the right authority, receives the official stamp, and seals it into the WAL in a single transaction. Switch country with one field.

MX

SAT

CFDI 4.0 (PAC timbrado)

GA
ES

AEAT

Facturae 3.2 / VeriFactu / SII

GA
EU

Peppol

UBL 2.1 / BIS 3.0

GA
IT

Agenzia delle Entrate

FatturaPA

Connector ready
BR

SEFAZ

NF-e

Roadmap
FR/DE

DGFiP / CEN

Factur-X / ZUGFeRD

Roadmap
curl — issue a CFDI 4.0 invoicefiscaldb
$ curl -X POST https://api.fiscaldb.io/v1/invoices \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "external_id": "FAC-2026-001",
    "country": "MX",
    "format": "Cfdi",
    "submit": true,
    "validation_mode": "strict",
    "payload": "<cfdi:Comprobante ...>"
  }'
All connectors
No migration

Speaks PostgreSQL. Speaks MySQL. Doesn't ask you to migrate.

psqlfiscaldb
$ psql -h fiscaldb -p 5432 -U admin -d fiscal
fiscal=> SELECT COUNT(*) FROM invoices
         WHERE country = 'MX';
mysqlfiscaldb
$ mysql -h fiscaldb -P 3306 -u root -p
mysql> SELECT * FROM invoices
        WHERE tenant_id = 'acme'
        LIMIT 10;
fiscaldb-clifiscaldb
$ fiscaldb-cli "SHOW WAL STATUS"
segment    0007.fseg
lsn        0x000004a1
chain      verified

INSERT/UPDATE/DELETE on invoices are rejected by design. Mutations happen as append-only events: corrections, cancellations, credit notes.

Who it's for

If invoices are evidence in your world, this is for you.

Governments & tax authorities
Fintechs
Banks
ERP vendors
E-invoicing providers
Large enterprises
Engineering

Engineered in Rust for correctness under audit

A pure-Rust engine with zero unsafe in its critical paths, deterministic crash recovery, and reproducible benchmarks. Ships as a single, signed binary with no external daemons. Distributed exclusively as licensed, signed releases — never from a public source repository.

Deterministic recovery
One binary, no daemons
Reproducible benchmarks
Zero unsafe in critical paths
Enterprise

Commercial license, deployed your way.

On your own infrastructure or as a managed cloud. Volume-based licensing with SLAs, dedicated support and compliance reviews.

Contact salesSee pricing

Invoices are records. Fiscal evidence is infrastructure.

Stop bolting compliance onto a general-purpose database. Build on the engine designed for it.

Stop bolting compliance onto Postgres. Talk to engineering.

See a TSA-sealed, hash-chained record land on disk in a single transaction.

Book a demoRead the docs