Frequently Asked Questions

Find answers to the most common questions about Databasus, including installation, configuration and backup strategies.

Why does Databasus not use raw SQL dump format for PostgreSQL?

Databasus uses the pg_dump's directory format with zstd compression at level 5 instead of the plain SQL format because it provides the most efficient balance between:

  • Backup creation speed
  • Restore speed
  • File size compression (up to 20x times smaller than plain SQL format)

This decision was made after extensive testing and benchmarking of different PostgreSQL backup formats and compression methods. You can read more about testing here PostgreSQL backups: comparing pg_dump speed in different formats and with different compression.

Databasus will not include raw SQL dump format, because:

  • extra variety is bad for UX;
  • makes it harder to support the code;
  • current dump format is suitable for 99% of the cases

Where is Databasus installed if installed via .sh script?

Databasus is installed in /opt/databasus/ directory.

Why doesn't Databasus support PITR (Point-in-Time Recovery)?

Databasus intentionally focuses on logical backups rather than PITR for several practical reasons:

  1. Complex setup requirements — PITR tools typically need to be installed on the same server as your database, requiring direct filesystem access and careful configuration
  2. Restoration limitations — incremental backups cannot be restored without direct access to the database storage drive
  3. Cloud incompatibility — managed cloud databases (AWS RDS, Google Cloud SQL, Azure) don't allow restoring external PITR backups, making them useless for cloud-hosted PostgreSQL
  4. Built-in cloud PITR — cloud providers already offer native PITR capabilities, and even they typically default to hourly or daily granularity
  5. Practical sufficiency — for 99% of projects, hourly or daily logical backups provide adequate recovery points without the operational complexity of WAL archiving

So instead of second-by-second restoration complexity, Databasus prioritizes an intuitive UX for individuals and teams, making it the most reliable tool for managing multiple databases and day to day use.

How is AI used in Databasus development?

There have been questions about AI usage in project development in issues and discussions. As the project focuses on security, reliability and production usage, it's important to explain how AI is used in the development process.

AI is used as a helper for:

  • Verification of code quality and searching for vulnerabilities
  • Cleaning up and improving documentation, comments and code
  • Assistance during development
  • Double-checking PRs and commits after human review

AI is NOT used for:

  • Writing entire code
  • "Vibe code" approach
  • Code without line-by-line verification by a human
  • Code without tests

The project has:

  • Solid test coverage (both unit and integration tests)
  • CI/CD pipeline automation with tests and linting to ensure code quality
  • Verification by experienced developers with experience in large and secure projects

So AI is just an assistant and a tool for developers to increase productivity and ensure code quality. The work is done by developers.

Moreover, it's important to note that we do not differentiate between bad human code and AI vibe code. There are strict requirements for any code to be merged to keep the codebase maintainable.

Even if code is written manually by a human, it's not guaranteed to be merged. Vibe code is not allowed at all and all such PRs are rejected by default (see contributing guide).

We also draw attention to fast issue resolution and security vulnerability reporting.

How to backup Databasus itself?

If you want to backup your Databasus instance (including all configurations, databases and credentials), follow these steps:

  1. Go to /opt/databasus (or the folder where you installed Databasus)
  2. Navigate to the databasus-data directory

You need to backup:

  • secret.key — encryption key for your credentials
  • /pgdata — internal PostgreSQL database of Databasus that contains all your configurations and backup metadata

If you use local storage for backups, you can also backup the backups folder.

Note: The secret.key file alone is not sufficient to restore encrypted backups. You also need the /pgdata folder, which contains the encryption metadata required for decryption.

To restore Databasus on another server: simply recreate the databasus-data folder structure with the backed up files and start Databasus.