When a trial expires, services are torn down, and upgrading to a paid plan triggers fresh deployments with new volumes - this is why you see a single deployment per service at the same timestamp with an empty database (schema intact from the image, but no user data). Unfortunately, we do not provide data recovery in this scenario, and the previous volume data is not retrievable. Going forward, we recommend enabling volume backups on your MySQL service so you can self-restore if needed.

Brutal.

Slight correction, you simply did not have a volume; without a volume, data cannot persist.

Hey Brody, appreciate the quick response.

I hear you on the volume point, but what doesn't add up for me: the MySQL service ran reliably for ~30 days with active daily reads and writes from multiple users. Schema migrations were applied, data was persisted across multiple app redeployments. The DEV database had columns and enum values that don't exist in any other database - the app would have crashed on startup if those weren't there, right? If there was truly no volume, I'm not sure how that's possible without a single data loss event over that period.

I clearly blew it with the lack of backups here - it was one of those situations where I started some good ideas and got pulled in other directions.

Super bummer about the data here. I'm gonna get roasted lol

Thanks for your help and chiming in.

I have to admit, though - "paused" sounds a lot better than what I've experienced here. I 100% had a volume and data was actively being written and the environment worked perfectly. This wasn't a pause. You guys might want to revisit the language on this one.

MySQL can run without a volume; however, without one, data is written to ephemeral file storage and lost on any redeploy, not just when running out of credits.

I hear you on the technical explanation. But look at what I'm seeing on my end:

Audit Logs (All Time): Only two events exist - both from today (May 21) when the redeployment happened. The entire history of my account activity over the past month has been wiped. This is why it looks like I "never had a volume" - there's no record of anything before today.

MySQL Metrics (30d - from April 22): Network traffic shows active egress/ingress on multiple days before May 21. Network traffic shows active egress/ingress on multiple days before May 21 - that's queries being served to real users.

I feel like the metrics prove the database was running with data. The audit logs prove everything was wiped clean during the trial expiration. I'm not disputing how MySQL works - I'm saying it seems evidence shows I had a functioning database with persistent data, and it was destroyed along with all records of its existence. Additionally, the app service was redeployed multiple times over the past month as I pushed code updates. If the MySQL data was truly non-persistent/ephemeral, it would not have survived those redeployments. But it did - users continued to log in and access their data after every push. Of course, I can't show you those deployment records because the audit logs were wiped along with everything else. My application's codebase defines database schema columns that only existed in this MySQL instance - they don't exist anywhere else. The app would fail on startup if those columns weren't present. It ran successfully for 30 days. The code is in my GitHub repo with commit timestamps (happy to screenshot) proving when those schema changes were deployed. Paused and permanently deleted are not the same. SQL backups would have saved me here, yes. But, if I would have known this would happen if I let the trial expire, I would have upgraded beforehand. No one wants to experience something like this - if it can be avoided in any future cases with proper communication, I think that's a good idea. Am I missing something here?

It is what it is at this point, I guess. I'll move on. Thanks.

I'm sorry, but you are mistaken. You never deployed MySQL with a volume from the very beginning. MySQL was running, just without persistent data. Deploying your application is separate from your database and does not affect it. Again, the data loss was not caused by the trial ending; it was caused by there never being a volume.

Your audit logs do not actually display data from account creation. Given you were originally on Trial with and are now on Hobby.