Two things
we built in-house

A database client and our own platform. Each one says what it is, how it is built, and what it shows for an audit.

For your production database, read how The Five-Day Database Audit works, or contact us.

NiceDB execution plan view: the slowest step is highlighted and a CREATE INDEX is suggested — Open source (GPL). Screenshot taken on demo data. nicedb.app · source on GitHub

NiceDB: database tooling

A desktop database client in Rust that connects to 24 engines plus any ODBC driver, from PostgreSQL and SQL Server to MongoDB and Redis. Production connections open read-only, and every write has to be switched on by hand.

Facts

It reads execution plans into one model, then writes the CREATE INDEX it recommends for the slow step.
The production guard lives in the core, not in the interface. Writes stay open for a set time (10 minutes by default) and need the connection name typed.
UPDATE or DELETE without WHERE, DROP and TRUNCATE ask for confirmation. Every write goes into a log.

What it shows for an audit

We wrote the code that turns a slow plan node into an index recommendation. The audit does the same with your slowest queries. Production is read-only by default in the client, and our collection script works the same way.

Our multi-tenant platform

A .NET 10 modular monolith built to serve many tenants from one codebase. Each tenant gets its own modules switched on and configured from an admin screen, with no code change.

Facts

It sits on PostgreSQL with pgvector, and its schema has grown migration by migration with EF Core.
End-to-end tests start real PostgreSQL, Redis and S3-compatible storage in containers and walk 14 steps, from login to a per-tenant audit trail.
Per-tenant secrets are encrypted with AES-GCM. Sign-in uses JWT with two-factor authentication and refresh tokens, behind rate limiting and security headers.

What it shows for an audit

We look after a PostgreSQL schema of our own, migration by migration, and test it against the real engine. The audit looks at what an ageing schema leaves behind: indexes, bloat, vacuum, locks and connections.