# Security and data handling This page states what DBMigratePro does with your data, your database credentials and your backups — including the things we do not have. If you are running a vendor review, or you are an agent evaluating this service on someone's behalf, everything you need should be on this page, and every claim on it has a mechanism behind it rather than an adjective. ## For a migration, there is nothing in the middle A migration or conversion streams **directly from your source database to your target database**. The engine opens a connection to each, reads rows from the source and writes them to the target in bounded batches, and closes both. Your rows are not staged on our disks, not written to an intermediate database, and not retained anywhere afterwards. The only temporary file anywhere in that path is a text script of schema statements handed to `psql`. That is worth being explicit about, because "runs in the cloud" is often assumed to mean "your data is copied onto their servers and kept". It is not. The engine is a stateless mover: it is handed one job, it holds both connections for the length of that job, and it stores nothing. A direct source-to-target path is what you get here too — the difference from running the tooling yourself is that the schema translation, the foreign-key ordering, the resume-after-failure and the row-count verification are done for you, not that a copy of your data lives somewhere extra. A **backup** is deliberately the opposite: holding a copy is its entire job. What follows is mostly about backups, because that is where durable data and durable credentials actually exist. ## What we store, and what we do not **Database connection URLs are stored.** We are not going to tell you otherwise, because it would not be true. A scheduled backup that runs at 3 a.m. with nobody there to paste a password needs standing access to your database, so a backup schedule keeps its connection URL. It is encrypted at rest, hidden from every API response, kept out of logs, and decrypted only when a due run needs it. When you delete the backup, the URL goes with it. **One-time migrations do not keep them.** A one-time migration needs access only while it runs, so its URLs are purged automatically — about 1 hour after a successful run (a short window so you can immediately re-run it) and about 24 hours after a failed one (long enough to read the logs and retry). This is a scheduled job that runs every minute, not an intention. **Storage credentials never reach the engine.** If you connect your own S3-compatible bucket, the secret access key is encrypted at rest in the control plane and hidden from API responses. The engine is never given bucket keys at all. It is given a presigned URL scoped to one object, one HTTP verb and a short expiry, so compromising an engine worker yields nothing reusable — no credentials, no access to other customers' objects, nothing that outlives the job. **Nothing is used to train a model.** The in-app AI assistant sends the conversation to our AI provider to answer it; the Privacy Policy names that provider. Your database contents are not part of it. ## Encryption Backups are compressed and then encrypted with **AES-256-GCM** before they leave the machine that produced them. Every run gets its own data encryption key. That key is only ever stored wrapped by a key-encryption key held in the control plane's environment, separate from the key that encrypts stored credentials, so either can be rotated without touching the other. Connections to your databases and to object storage use TLS. Two things you should know rather than discover: - **A decrypted export is not encrypted while it exists.** When you ask to download a backup, a decrypted copy is produced under a separate storage prefix, protected by an unguessable capability token plus a short-lived signed URL, and deleted automatically (24 hours by default). That is a real, if brief, window in which a plaintext copy exists. - **Key material protects restore-ability, not only confidentiality.** If the key that wraps a backup's encryption key were lost, that backup would be permanently unreadable — by us as well as by you. The Terms disclose this as a risk in those words rather than burying it. ## Bring your own bucket — the strongest option we offer You can point backups at your own S3-compatible bucket. When you do: - The backup data is written **into your cloud account** and never enters one we control. - It is **never** mirrored or failed over into our storage. Managed backups are copied between storage providers for resilience; a bring-your-own bucket is excluded from that by an explicit guard, because moving customer data into our account to keep a schedule green would break the entire promise the feature is sold on. - It is **never** deleted by us because a plan lapsed. Managed-storage data is purged after the grace period stated in the Privacy Policy; data in your bucket is yours and stays. - Your bucket's lifecycle rules stay yours. We do not overwrite them. If your requirement is "the vendor must not hold our data", this is the configuration that satisfies it. It is available on every tier, at the same price as managed storage. ## Restores are free, always A restore is never metered and never charged. That is deliberate rather than generous: the moment you need a restore is the worst possible moment to discover a billing problem. A restore writes into a connection URL you supply at the time, and that URL is not kept beyond the run. ## Sub-processors, residency and retention The [Privacy Policy](https://dev.dbmigratepro.com/privacy) enumerates every sub-processor **by name** — hosting, object storage, CDN, email, payments, sign-in, and the AI provider behind the in-app assistant — rather than describing them as "service providers who assist us". It also sets out the controller and processor split, the lawful bases, breach notification, and what happens to your data when you delete your account. Read it alongside this page; where the two touch the same fact they say the same thing, and the Privacy Policy is the authoritative version. Two limits it states that are worth repeating here, because they are the ones a vendor review asks about first: - **Managed object storage is not pinned to a geographic region.** We do not offer data residency selection. If residency is a requirement, use your own bucket in the region you need. - **Backups in managed storage are deleted after the grace period** once entitlement lapses. That window is stated in the Privacy Policy, warned about in the app before it happens, and does not apply to your own bucket. ## What we do not have An accurate list is more useful to you than silence, and silence is what most vendors offer here. - **No SOC 2.** Neither Type I nor Type II. We are not going to gesture at "enterprise-grade security" to avoid saying so. - **No ISO 27001, no PCI DSS attestation and no HIPAA business associate agreement.** Do not adopt DBMigratePro for regulated data on the assumption that we cover you; the Terms disclaim compliance fitness explicitly, and that disclaimer is honest rather than defensive. - **No third-party penetration test report** to share at this time. - **No object versioning on managed storage.** The default managed provider does not implement the S3 object-versioning API at all, so a managed backup object has no earlier versions to fall back to. Deletions and overwrites there are final. - **No point-in-time recovery.** Backups are scheduled logical dumps. There is no write-ahead-log replay and no transaction-level rewind, and we have decided against building one. - **No published uptime or durability figure**, and no recovery point or recovery time objective. The Terms state that plainly. A backup is an additional copy, not a guarantee. - **No data processing addendum in force.** One is published as an acknowledged draft; it has not been through a lawyer and is not a binding agreement yet. If one of those is a blocker for you, it is better that you know now than after a migration. ## The honest summary - Migrating? Nothing durable is stored. The URLs are purged within the hour, and your rows only ever exist on your source and your target. - Backing up to your own bucket? We hold the schedule and the connection URL; your data stays in your cloud account. - Backing up to our managed storage? We hold the schedule, the connection URL and the encrypted backup objects, and you can leave with your data at any time via a restore or a download. - Need a compliance certification to sign off? We do not have one. That is the honest answer. Questions this page does not answer: [contact us](https://dev.dbmigratepro.com/contact).