No way.
At least right now, SwiftData shouldn't used for anything but quick-and-dirty PoC's, demos, or other limited-use, low-stakes things.
There are some good ideas in it, especially how it integrates with SwiftUI. But it's alpha quality right now.
The article actually oversells SwiftData, IMO. I don't think it wasn't usable in iOS 17.
And its concurrency story isn't great. E.g. if you want to do queries or other data access in the background, you'll need to create and maintain separate, Sendable variants of your models. Now, I get that SD is really a memory-based database (typically backed by sqlite), so you can probably do a lot right on the main thread, but you'll end up wanting to move some things for various reasons, and it's awkward and boiler-platey. Not to mention, models have a magical connection to containers. You can't see it directly, but try to instantiate a model without a container (for, you know, preview -- a core feature of SwiftUI).
There are also some creaky design decisions. On one hand, it acts like an ORM, that wants to persist an object graph. But it also leaks relational concepts all over the place. They probably should have picked one approach or the other... as it is, at every turn you have to figure out if they went relational or object graph, and program accordingly.
Now, CoreData has it's own issues, and, I assume, Apple is no longer going to focus on it, so I'm not sure it's a good idea to use it either.
Personally, I've just started using sqlite3. With that you've got all the speed, power, and reliability, and don't have to hope Apple doesn't blow up your project on each release.
(I use some utilities to take the boiler plate out of passing Swift values as parameters and receiving Swift values as results. Other than that, you can just call the sqlite3 C API directly.)