Nobody owns the database, so start with a restore point
In a small team the database is everyone's and no one's. It was set up once, it works, and it is looked at when it hurts. The first condition for any change, by us or anyone, is a backup that has actually been restored. A dump file that has never been loaded is a hope. PostgreSQL's own manual says its dump tool makes consistent exports but is not generally the right tool for regular production backups except in simple cases, so check how yours are really made.
If you have no tested restore point, make that the first job. The off-site backup and restore-test job covers it for a website database. Everything else on this page assumes you have one.
- Restore the latest backup into a scratch environment and look at it.
- Note how old it is, and how long the restore took.
Match the problem to the smallest job
A job that quietly stopped, or runs twice: the cron job and the idempotency job, each on one job and one test host. Duplicate rows in one table: the merge job on a restored copy, with the removed rows archived so the merge can be reversed. A schema change you are afraid of: the add-column job for a new column, or the column-change job for converting an existing one, each rehearsed with a way back. A general feeling that the database is unwell, with no one looking: the monthly review, from exports your engineer sends, without our holding a connection.
Each job runs on a copy, test host or staging system you prepare, with personal data removed or replaced, and hands back scripts or pull requests. You apply changes yourself after your restore point. Prices are untested proposals and payment follows the agreed checks and your sign-off.
- One symptom, one job, one acceptance test.
- The monthly review is for watching, not for urgent fixes.
If you are on SQLite
Many small teams start on a SQLite file. It is forgiving: loose types, foreign keys off unless enabled, one writer at a time. Run the integrity and foreign-key checks on a copy to see what has accumulated, and measure whether "database is locked" comes from long write transactions before deciding the engine is the problem. None of the fixed jobs on this page covers a SQLite file, because they are written for PostgreSQL and MySQL and stop on any other engine. A SQLite-specific scope, including a move to another engine, would be quoted separately.
- Run the checks on a copy, never the live file.
- Do not send the database file in the first enquiry.
Ask without sending anything risky
Send the engine and version, what you see in plain words, whether you have a restored backup, and an invented example of the problem. Do not send credentials, dumps, files or real customer values. An enquiry books nothing and charges nothing.
This page is a buyer hypothesis. It is not evidence that small teams have requested or paid for these jobs.
Sources and limits
- PostgreSQL 18: pg_dump Checked 2026-10-11.
- pg_dump makes consistent exports of one database without blocking other users, and the manual notes it is not generally the right tool for regular production backups except in simple cases.
- Healthchecks.io documentation Checked 2026-10-11.
- Heartbeat monitoring raises an alert when an expected check-in does not arrive.
- SQLite: Appropriate uses Checked 2026-10-11.
- SQLite allows one writer at a time and suggests client/server databases for heavy write concurrency or many machines accessing the file over a network.