OpenShip Database Backup: Managed vs Self-Hosted Cost

OpenShip's pricing page checked on August 2, 2026 lists Cloud at $20 per seat per month and says daily backups and point-in-time recovery are included. Its self-hosted Hobby option is listed at $0 forever, but you run the platform on your own servers. OpenShip pricing details

Your backup job succeeds but nobody has tested a restore → choose the managed path or schedule a full recovery drill before launch.

You already operate databases, isolated storage, monitoring, and recovery rehearsals → self-hosting can be cheaper, but only after you price your time and failure exposure.

This guide is for you if:

You are moving an OpenShip prototype into production.
Your AI SaaS must preserve Agent sessions, user files, and business state.
You are comparing a managed database with your own server and recovery responsibility.
You need a defensible disaster recovery cost before approving a deployment.

Start With The Recovery Decision

The wrong first question is, “Which backup option has the lower subscription price?”

The better question is, “What must be working after a failure, and who is responsible for proving it?”

OpenShip currently presents three relevant deployment shapes:

Managed: OpenShip Cloud handles the infrastructure layer and publicly lists backups as included.
Self-hosted: You run OpenShip and its services on infrastructure you control.
Hybrid: You keep sensitive or predictable workloads under your control while using managed capacity for selected services or bursts.

The official installation guide says OpenShip can run on your own Linux server or through OpenShip Cloud. It also describes the desktop application as bundling the API, dashboard, and database for local development. That distinction matters: a local database bundled for convenience is not automatically a production backup design. OpenShip installation guidance

Use this decision rule:

Choose managed backup when your team lacks a named database owner, cannot inspect failed jobs frequently, or has a firm recovery requirement.
Choose self-managed backup when you already maintain database systems, off-site storage, credentials, monitoring, and repeatable restore procedures.
Choose hybrid when the database needs stronger control but previews, non-sensitive workloads, or burst capacity do not.

A low invoice does not compensate for an untested recovery path.

Map What Must Be Recovered

A PostgreSQL dump alone may not restore your AI SaaS. Before comparing plans, divide persistent state into separate recovery units.

Recovery component	What it may contain	Failure if omitted
PostgreSQL	Accounts, billing records, prompts, Agent metadata, permissions	The application starts with missing business state
Redis	Queues, rate limits, sessions, temporary Agent state, streams	Jobs disappear or users are logged out
Object storage	User uploads, generated files, exports, attachments	Database rows point to missing files
External task queues	Pending jobs, scheduled work, webhook retries	Background processing does not resume correctly
Configuration and secrets	Connection strings, encryption keys, environment values	Restored services cannot authenticate
Deployment definition	Service names, volumes, domains, health checks	Recovery becomes a manual rebuild

OpenShip's public platform page lists PostgreSQL, Redis, MongoDB, MySQL, object storage, and worker-style services among its platform capabilities. It also states that Cloud and self-hosted deployments use different infrastructure responsibilities. Do not treat the presence of a service in the platform as proof that every service has the same backup, retention, or restore behavior. OpenShip platform capabilities

For an AI SaaS, add two questions to your inventory:

Can the data be regenerated?
Does the data contain real users, private files, financial records, or contractual history?

If generated embeddings can be rebuilt from source documents, they may have a lower recovery priority than user accounts or payment records. If Agent state controls an active workflow, losing it may create duplicate actions even when the primary database is restored.

A backup file is an artifact. A recovery plan is a tested sequence that brings the complete service back with the correct data and credentials.

Compare The Real Cost Variables

The cost of OpenShip database backup has at least five parts:

Total monthly cost =
backup storage
+ transfer and replica storage
+ recovery infrastructure
+ maintenance labor
+ expected failure cost

Do not fill these variables with invented fixed prices. OpenShip's public Cloud pricing page provides a seat-based price and describes included backup features, but it does not turn every possible storage volume, retention rule, recovery event, or self-hosted architecture into one universal cost. Recheck the official plan page before procurement. OpenShip's current pricing page

Cost variable	Managed path	Self-managed path	What you must verify
Backup storage	May be bundled or governed by plan terms	Separate storage account or disk	Capacity, growth, retention, deletion
Backup frequency	Defined by the managed offering	Your schedule and tooling	Job interval and missed-job alert
Point-in-time recovery	Listed for OpenShip Cloud	Must be confirmed and configured separately	Log shipping, replay window, restore method
Off-site copy	May be part of the service design	You must create and monitor it	Different failure domain and access
Database upgrades	Provider responsibility within plan scope	Your responsibility	Version compatibility and rollback
Restore operation	Provider workflow or supported console path	Your runbook and operator	Credentials, extensions, network, DNS
Labor	Lower routine workload	Script, monitor, clean, test, repair	Hours per month and on-call burden
Failure risk	Shared with the provider under its terms	Concentrated on your team	Accountability and escalation route

The self-hosted price can appear to be zero because OpenShip lists the self-hosted Hobby option at $0 forever. That figure does not include your server, storage, operator time, recovery environment, or the cost of discovering that a job failed several weeks earlier. Self-hosted and Cloud plan comparison

The managed price also is not automatically the final cost. You still need to check seat count, bandwidth, retention terms, export access, data location, and any workload that sits outside the managed scope.

Price Maintenance Before Storage

A self-managed backup is a small operations system. It needs ownership.

The minimum workload usually includes:

Writing a database-aware backup command.
Sending the output to storage that is not the primary server.
Encrypting the backup and protecting the key.
Alerting when a job fails or produces an unexpectedly small file.
Cleaning old copies according to a written retention policy.
Checking database and backup-tool compatibility after upgrades.
Restoring into an isolated environment.
Reconnecting the application and validating real business flows.

OpenShip's self-hosting documentation describes running the platform on your own server and gives baseline infrastructure guidance, including a minimum of 2 CPU cores, 2 GB RAM, and 20 GB disk, with a recommended 4 or more cores, 4 GB or more RAM, and 50 GB or more SSD. Those figures describe platform installation requirements, not a complete backup or recovery environment. OpenShip self-hosting requirements

If you spend one hour each week checking jobs, rotating storage, investigating alerts, and testing recovery, that is more than four hours of monthly operating work. Use your actual loaded engineering rate in the formula. If nobody has that time assigned, the self-managed plan is not actually funded.

This is also why “write a script” is not the same as “operate a backup system.” A script can create a dump. It cannot decide whether the dump is complete, whether the storage account is reachable, or whether the restored application can process a queued Agent task.

Select A Retention Policy By Failure Type

“Keep backups for 30 days” is not a complete policy. You need to connect retention to the way data loss is discovered.

Consider these events:

Accidental deletion: You may discover the error quickly and need a recent restore point.
Corruption: Bad data may remain unnoticed until a later report or customer complaint.
Credential compromise: You may need a clean copy from before the compromise.
Billing or legal dispute: You may need historical records beyond normal operational recovery.
Infrastructure loss: You need an independent copy and enough configuration to rebuild elsewhere.

For a personal prototype, a short retention window can be reasonable when the database contains synthetic data and the application can be rebuilt from source. You should still export deployment configuration and keep one isolated, verifiable recovery copy.

For an independent developer, retention should be simple enough to inspect. A complicated policy that nobody checks is weaker than a smaller policy with a known restore path.

For a small team, separate operational recovery from long-term retention. The first is for recovering from a bad deploy or accidental deletion. The second is for delayed discovery, compliance requests, or customer history.

For a production AI SaaS, calculate the storage variable instead of guessing:

Backup storage =
database size
× backup copies
+ change volume
× retention period
+ object-file copies
+ metadata and logs

The database size alone is not enough. User files and generated outputs can grow faster than relational records. Redis may also be disposable, recoverable, or business-critical depending on whether it contains only cache entries or durable streams and task state.

Use Team Stage As The Decision Filter

The same OpenShip database backup choice can be sensible for one team and reckless for another.

Team stage	Typical risk	Better default	Condition to change
Personal prototype	Data can be regenerated, but configuration may be lost	Simple self-managed export plus one verified copy	Move to managed when real user data enters the system
Independent developer	Maintenance depends on one person	Managed or hybrid	Self-manage only with scheduled checks and documented recovery
Small team	Responsibility can be unclear between developers and operations	Managed backup with named access roles	Self-manage after ownership, permissions, and drills are formalized
Continuous AI SaaS	Downtime and lost Agent state affect customers	Managed or hybrid	Self-manage only when RPO and RTO are tested
Sensitive-data team	Location, deletion, audit, and key control matter	Controlled self-hosted or hybrid design	Use managed only after contract and plan terms meet requirements

OpenShip's public materials describe Cloud as managed and self-hosted as infrastructure that you operate. They also describe a hybrid model for combining Cloud and your own servers. This makes hybrid deployment useful when your data sensitivity and recovery requirements differ by service, but it also creates more boundaries to document. OpenShip deployment shapes

For a small team, permissions matter as much as backup frequency. Ask:

Who can create, download, delete, or restore a backup?
Is the backup storage account separate from the production account?
Can one compromised application credential delete every copy?
Who approves a restore that may overwrite newer data?
Can a departing engineer take the only encryption key?
Are audit records retained long enough to investigate changes?

If you cannot answer these questions, adding more replicas may increase the number of places that can fail without improving recovery.

Walk Through The Recovery Milestones

Use this sequence before buying a managed plan or building a self-managed stack.

Milestone 1: Define the recovery boundary

Write down whether recovery includes only PostgreSQL or also Redis, object storage, Agent state, external queues, secrets, domains, and deployment configuration.

Milestone 2: Set acceptable loss

Define the maximum data loss you can tolerate. Express it as a time window, not a vague goal. Then define the maximum service interruption you can accept.

Do not copy a provider's advertised capability into your self-hosted design. A managed point-in-time recovery feature does not prove that your own server is archiving logs or retaining them correctly.

Milestone 3: Assign the owner

Name one person responsible for backup monitoring and another person who can perform a restore. For a solo developer, document the procedure while you still remember how the system works.

Milestone 4: Separate the backup destination

Do not leave the only backup on the same disk, account, or server that runs the database. Create a separate access boundary and test that the application cannot delete the recovery copies with its normal credentials.

Milestone 5: Generate and inspect a backup

Check the timestamp, size, checksum, database object count, and expected tables. A green scheduled task is not enough.

Milestone 6: Restore in isolation

Use a disposable server or isolated environment. Restore the database first, then the files, secrets, queues, and service configuration. Record every command and manual decision.

Milestone 7: Reconnect the application

Run real checks:

Sign in as a test user.
Load an existing Agent session.
Read and create a business record.
Download a stored file.
Submit a background task.
Confirm queue processing.
Verify billing or usage records.
Check logs and permissions.

Milestone 8: Record the evidence

Save the backup identifier, restore timestamp, database version, operator, failed steps, and final validation result. Repeat the drill after major database, storage, or deployment changes.

Answer The Questions That Break Budget Reviews

Does self-hosted OpenShip back up automatically?

The public self-hosted documentation explains how to run OpenShip on your own infrastructure, but you should not infer a backup schedule from the Cloud feature list. Confirm the exact deployment documentation for your version. If frequency, retention, storage destination, and restore commands are not explicitly documented, treat them as tasks your team must design and operate.

Is managed backup cheaper than writing your own scripts?

It depends on whether your team prices labor honestly. Managed backup may have a visible recurring charge. Self-managed backup has storage, transfer, monitoring, maintenance, security, upgrades, and recovery rehearsal costs. If a failed job can remain unnoticed until an incident, include that expected risk in the comparison.

How long should a database backup be retained?

Use separate retention classes. Keep recent copies for operational mistakes, periodic copies for delayed discovery, and longer-term copies only when business, contractual, or compliance needs justify them. Your data classification, deletion obligations, and recovery history should determine the policy.

Why can a successful backup still fail to restore?

The backup may contain the database but not the required extension, encryption key, object files, queue state, or compatible configuration. It may also restore successfully while the application still points to the wrong hostname or cannot authenticate. Validate the complete service, not only the database command.

How do you estimate recovery cost before launching?

Inventory every persistent component. Write the target loss window and downtime window. Price storage, replicas, restore compute, operator hours, monitoring, credentials, and the test environment. Then run one complete drill and replace assumptions with measured steps. The first rehearsal is usually the most valuable estimate you can obtain.

Use This Pre-Launch Checklist

[ ] List PostgreSQL, Redis, object storage, Agent state, queues, secrets, and deployment configuration.
[ ] Mark each item as regenerable, recoverable, or business-critical.
[ ] Define the maximum acceptable data loss window.
[ ] Define the maximum acceptable service recovery time.
[ ] Confirm whether the selected OpenShip deployment explicitly includes backup and recovery features.
[ ] Record backup frequency, retention, export, deletion, and access rules.
[ ] Create a separate backup destination or verify the managed isolation boundary.
[ ] Assign a backup owner and a recovery operator.
[ ] Generate one backup and inspect its contents.
[ ] Restore it into an isolated environment.
[ ] Reconnect the application and test a real Agent workflow.
[ ] Test user-file retrieval and background task processing.
[ ] Record the elapsed recovery time and every manual step.
[ ] Recalculate monthly cost using measured labor and storage assumptions.
[ ] Repeat the drill before production launch and after major upgrades.

Make The Final Choice After The Drill

If your current setup is a single self-hosted server, one local volume, hand-written scripts, and no scheduled recovery test, its apparent low cost hides three weaknesses: one infrastructure failure can remove both production and backups, maintenance depends on one operator, and “backup completed” may never have been tested as “service recovered.”

A managed OpenShip path can be the better operational choice when you need a named recovery workflow, included backup features, and less routine database maintenance. Self-hosting remains reasonable for teams that already control storage, access, upgrades, monitoring, and restore execution. Hybrid is useful when sensitive data needs a controlled location while less critical workloads need flexible capacity.

Run the isolated recovery drill first. Then choose the plan that matches the evidence, not the lowest line item. If you need a temporary build, test, or remote development environment while your long-running OpenShip architecture is being evaluated, you can compare Kvmkit's available Mac rental environments or review US East Mac rental options.

FAQ

Does self-hosted OpenShip back up my database automatically?

Do not assume it does. OpenShip's public Cloud materials describe included backups and point-in-time recovery, while the self-hosted materials describe running services on your own infrastructure. Treat backup frequency, retention, storage location, and restore testing as your responsibility unless the exact deployment documentation confirms otherwise.

Is managed backup cheaper than writing my own scripts?

Managed backup can cost more on the invoice but less in total effort. Self-hosted scripts only look cheaper when storage, off-site copies, monitoring, cleanup, database upgrades, failed jobs, credentials, and restore drills are assigned a zero labor cost. Compare the full monthly workload, not only the storage bill.

How long should an AI SaaS database backup be retained?

Retention should follow the business impact of lost data, not a universal number. Keep enough history to cover delayed discovery, billing disputes, accidental deletion, and recovery testing. For an early prototype, a short verified window may be acceptable. Production systems usually need separate operational, weekly, and longer-term retention policies.

Why can a backup report success but still fail during recovery?

A successful backup job proves that a file or snapshot was created. It does not prove that the database can be restored, that credentials still work, that required extensions exist, or that the application can reconnect. A valid recovery test must restore into an isolated environment and verify schema, records, files, queues, secrets, and application behavior.

How should I estimate recovery cost before launching an AI SaaS?

List every persistent component, define the maximum acceptable data loss and service downtime, then price the work needed to meet those targets. Include database storage, object files, Agent state, external queues, replicas, backup transfer, restore infrastructure, engineering time, and an occasional full recovery rehearsal.