If it was live in production it was a regression.
It’s still a “defect”, but any company that worries far too much about which bugs are regressions versus integration bugs , versus unclassifiable, needs to write a better rule book. Your job as a tester is to “talk” to the ship-ability of the product. It’s a waste of time in my opinion to worry about classifications while there is a house-fire.
It’s hard to be diplomatic as @mirza points out. But that’s how you will get things fixed quicker. And as long as you can use it to learn about the software development lifecycle in more detail, you all can win. You might want to also talk about “planned breakages” alongside this in future, because sometimes a break can prevent other kinds of testing, so getting warning will help other teams plan their work. The only way devs can warn you that things might blow up soon, is if there is a daily scrum meeting where devs and test and “ops” are all in the same room together.
Basically also helps to think of software creation as a very very long conveyer belt (My first job we did work with coal mining.) And if a developer breaks things, they either need to come under pressure to revert their change completely, and prepare a better change, or they need to plan to break and then plan to fix it, but not on a Friday afternoon. Any downtime ends up costing a lot of other people and teams time. also there is a greater risk during downtime that any testing that you could not do, means that other teams are unable to contribute their code either. It does not help to increase pressure from any external teams who also get blocked, so diplomacy is key.
This might also mean you need to learn how to look at code changes and how to even revert a change if you can get agreement to do so. In this case someone changed a DB, which means none of this advice about code will help, but that possibly points to a systemic architecture flaw, since all data in the DB (I’m assuming this is not production) should be test-only data, and all the DB schema and procedures and triggers should be in the same version-control repository too.