I found that even a proprietary product can improve your skills in a general way, and it has the advantage of being pre-selected for "what works". Anecdata: Google Firebase, specifically Firestore. On a superficial level, it's just another NoSQL database and you'd probably (rightfully) realize all the things that MongoDB can do that Firebase cannot. OTOH, I learned two things from it that I didn't from previous work with MySQL and PostgreSQL. (Note that I did not previously work with MongoDB beyond some tinkering, so maybe that would work as well).
The first was data-change notifications, i.e. getting notified when a record changes. I toyed around with this idea with MySQL some time ago, masquerading my server as a replica server, but generating derived data form it. IIRC PostgreSQL has something similar with WAL streaming. With Firebase, I learned how this can actually work and convinced me that the idea is sound. It definitely encourages me to actually do this for real when I work with PostgreSQL again.
The second is what PostgreSQL calls row-level security, i.e. using the data in a row to determine required permissions. In Firestore, this is the only kind of permission control (except for all-in admin accounts), and it showed me how this easily prevents a whole range of security issues that can occur through bugs in a back-end server.
The specific coding around Firestore is shallow as you said, and non-transferable, but understanding what is possible is something that will definitely help me in the future, with other databases.
This might be true in some cases. For example, I'd argue that doing a Cisco CCNA/CCNP certification is going to teach people not entirely familiar with the matter a ton of useful stuff about network technology in general even if they go to work on a Juniper site.
On the other hand, I've rejected all certs that relate to "_______ certified architect/developer/whatever", most famously pushed in our company as the "AWS certified in-house advertiser".
In any case, those certs are extremely lucrative business.
The first was data-change notifications, i.e. getting notified when a record changes. I toyed around with this idea with MySQL some time ago, masquerading my server as a replica server, but generating derived data form it. IIRC PostgreSQL has something similar with WAL streaming. With Firebase, I learned how this can actually work and convinced me that the idea is sound. It definitely encourages me to actually do this for real when I work with PostgreSQL again.
The second is what PostgreSQL calls row-level security, i.e. using the data in a row to determine required permissions. In Firestore, this is the only kind of permission control (except for all-in admin accounts), and it showed me how this easily prevents a whole range of security issues that can occur through bugs in a back-end server.
The specific coding around Firestore is shallow as you said, and non-transferable, but understanding what is possible is something that will definitely help me in the future, with other databases.