That is how it tends to work in small companies, but that is how it always used to work for small companies: at a small scale an expert database person was often seen as a grandiose expense when all the devs can do the basics. This is not really a factor of ORMs and noSQL becoming popular recently.
ORMs still have datastores behind them that someone needs to understand and be able to monitor, backup, repair, analyse, scale & optimise and as companies and/or projects grow it still pays to have a specialist in that area. Trusting devs with no data handling specialism is often fine on a small scale, but can lead to significant problems when scaling up. It is quite common to see people gush about an ORM or noSQL solution and claim it means they don't need to worry about the database, only to complain bitterly later when something they tested on a few thousand records falls to the floor when asked to deal with tens of thousands or millions or more (or sometimes even "a few thousand plus one" for really bad designs) and they have quickly got to the point where throwing more hardware at the problem is no use. You'll often find massively complicated caching layers getting created which would not be required if a little more thought had gone into either the initial design of the data store (or a later refactor) - those layers need development and maintenance too so those projects are often not saving money long term by not having a "data guy". In fact if you can keep a foot in both camps (dev and data) then there is much interesting work (and good money) in certain "architect" roles: people either designing the model for projects or earning their bread from taking overly complicated & inefficient monstrosities and helping the dev teams turn them into relatively sleek & scalable creations.
Also don't constrain yourself to being a DBA for a dev team: all of our clients (banking types, councils, a small airline or two) have an infrastructure department in part populated by DBAs who are responsible for making sure their data is appropriately handled. They challenge us (and other suppliers) to ensure we are following good practise, they are responsible for wider issues such as integration of data from systems from desperate suppliers, and they are of course responsible for maintaining in-house databases (mirrors, backups, monitoring, ...) - so there are other places a DBA optimised skill-set is required.
Of course you must stay up-to-date with the newer tools, that goes without saying, but while the job overall has evolved a bit over the last decade it hasn't changed nearly as much as some would have you believe (nor I expect will it in the near future, though keep your ear to the ground for new developments to stay current and avoid obsolescence if I'm wrong about that).