Ok, I'm actually looking at that for the last few days, but would make the same question replacing Django with DRF.
It's great to be able to define a DB model, and in a few lines of code have the API endpoint for that DB entity up and running.
When you start getting to complex apps, you may find yourself fighting against the framework somewhat in order to keep your concerns separated, but that's a Hard Problem in general, and so I don't think it's a flaw of the framework itself (though there are a few areas where DRF is opinionated that I think it should not be). If you were using Flask, you'd have more freedom to tweak things when you get to this point, but you'd also have spent 1.5x the dev effort building all of the things that Django/DRF does already.
In short, if you don't know whether you need Django/DRF or Flask, you probably need Django/DRF. Once you have enough experience with Django/DRF to critique that stack's design decisions, you'll be in a position to make good decisions of your own with Flask if Django/DRF doesn't meet your needs.
(My last API was in Go and felt like too much work, even though it worked nicely in the end.)
With Django, would I be able and would it make sense to keep the SQL schema if I changed languages?
Django has the concept of `apps`, where each app gets its own namespace. So for model `foo` in app `app1`, you get a table `app1_foo`. Inside that table it's just the standard SQL columns that you'd expect. So you might need to override the default table name if your new ORM provides one, but no more than that.
The only other piece that might give you grief is the ContentType machinery; there's a content_type table that has a row for each model class, which lets you do generic foreign key lookups. It might be some work to duplicate that, if you start depending on it. But it's not super-complex; it's just <id, app_label, model> in that table.
Once you start adding on features like allowing writes, authentication+authorization, rate limiting, API discovery, client library generation, OAuth support, etc then something like DRF really makes sense.
DRF is pretty darn flexible and it uses Django so you get a lot of functionality for free, including the Django admin if you want a way to explore your data. DRF in no way forces you to use the Django models (or even any models at all).