I assumed this, from the 2022 roadmap, meant we would see a facility to dump databases (by target) to a .sql file but George said i needed to make a feature request so here it is.
The request is to be able to perform a .sql dump from databases within any target and the ability to restore that data to any target
Wish I could vote 100 times for this! This would be a game changer.
My main database currently has 88 tables (and growing), a few of them with 10,000 records or more. So that would be a very large sql file. So even if we had the ability to back up and restore individual or select tables as well, that would be huge.
Btw are you aware that we have dumping alike possibility by creating “database templates” under the context menu?
There you can save and reapply different database schemes / selection of tables with optional data save as well.
Might be something to check out 
See:
Thats the thing about .sql files, they are suprisingly small as they are just plain text.
Have used dumps of much bigger than that, literally100s of 1000s of records.
Thanks George, but how does that help with backups? Say i want work on a table, but I want to back it up first in case something goes wrong?
I agree with @brad , I am not sure how the Database Template would solve the issue. The Database Template feature seems more like when you have more than one project using similar data.
I am currently using MySQL Workbench to import/export data from my live and development site.
The Save Database Structure and Data is an option for the development site, but not the remote site with OrangeHost - I think because while OrangeHost supports Nodejs, it is not Docker Hosting.
The Database Templates does not solve any backup issues, that is not what they are for.
Their purpose is to create a library of reusable database snippets that you can use on multiple projects.
Complete database backups and versioning is a different topic.
But it is the reason for this Feature Request 
I don't think versioning is even that important but would be a bonus. I think the request is simply asking for a way to back up a database to an SQL file and the ability to. restore from an SQL file.
Is a 71 MB sql dump not considered large?
While I guess it would be convenient to have this in wappler, I use Navicat to manage my databases and it is very capable. I feel like this kind of database admin is outside of wappler’s wheelhouse and there are many viable alternatives that are purpose built for the task. Maybe I’m missing something though.
I agree. I wasn't keen on the addition of Database Manager in the first place, as, inevitably, it has taken so much time away from the development of other features, and has added to the burden of support. (I appreciate I'm probably in a minority in this view, but I'm sure Wappler will never compare to the likes of Navicat - which I use - and I hope it won't try.)
Anyway, I'm sure it will be necessary to put a cap on the Database Manager features at some point.
Maybe, but maybe not, but for sure you are not alone.
I'm in a similar situation, Wapplers DB manager is almost never used on anything I'm working on, its only use for me is to refresh schemas after DB changes from my preferred DB management tool - HeidiSQL - Wappler devs are top of their game, but they'll never be able to port the usability of HeidiSQL into Wappler.
I'd much rather the existing DB manager is capped, with no more enhancements, this would free up time for the team to concentrate on the front end components which are lacking in development (charts especially). There's a fair few items in the last roadmap that have stalled, it would be good to see them start back up again.
Same here.
Stopped using Wappler DB manager when I got lost progress of creating new tables.
Now I'm using a single SQL file that contains whole project structure.
For DB backup/restore I'm using pgAdmin.
Same boat. It is really only used to refresh schema. Although it seems that there is a fairly large pool of users that don't use it, it is a valuable tool to those (perhaps new) users that don't have an alternative. So it is still an important tool in the big picture. So I think if there is a way to improve it, it should be done. Within reason that is. I don't think it is required to make it a Navicat or anything, just the basics. And a way to quickly back up a database for those that don't have alternative options is a very valuable feature.
Ironically, this is not, i agree, mission critical.
I am now just totally confused what the wappler team meant in the 2022 roadmap by:
"Add cross database solution to make or restore full database backups"
if not similar to this feature request?