Making PostgreSQL recovery more accessible to developers.

Acrynite started with a simple observation: creating database backups is important, but being able to restore them reliably is even more important.

Why we are building Acrynite

Many teams have backups they have never restored. The gap shows up at the worst moment: a missing WAL segment, a dump that will not import, or a restore procedure nobody has run in a year.

We are building developer-focused tooling to make PostgreSQL backup and recovery workflows easier to configure, manage and verify. That means treating recovery as part of the backup process, and making it safe to practise a restore without touching production.

Our goal is to help developers build more resilient database infrastructure without adding unnecessary complexity.

Acrynite logo mark
01

Five principles we build by.

Reliability

Prefer predictable, well-understood PostgreSQL mechanisms over clever shortcuts.

Simplicity

Register once, run one command. Keep configuration small and readable.

Transparency

Say what works today, what is experimental, and what is only planned.

Developer experience

Clear commands, useful output and errors that tell you what to do next.

Open-source collaboration

Design and fixes happen in public, with testers and contributors.

02

Get involved.

Acrynite is developed in a public GitHub repository. Issues, design discussion and pull requests all happen there. Running a backup and restore test in your own environment and telling us what happened is one of the most useful contributions.