First, don't allow yourself to become too specialized in any specific area of database technology at the cost of not expanding your learning into other areas, and also don't allow your employer to pigeonhole you in a job for which you find boring. Don't become deeply involved in anything professionally unless you really love it, your learning something useful, and/or you are paid well above industry average. Watch SQLBits and PASS video conferences online, attend local SQL Server user group meetings and SQL Saturday events, and even go through the process of interviewing for job positions that interest you (even if you're not entirely earnest about changing jobs). Why? Because, this does a lot for expanding your horizon about what's out there and also it gives you an opportunity to measure how you stack up professionally with your industry peers. You may be the smartest database guy in your office, but having personally gone through the process of interviewing new hire candidates, I can tell you that most of the folks in our industry are seriously self-deluded about the breadth of their technical expertise in at least one major area. For example, if you don't know the fundamentals of how SQL Server locks, blocks, and deadlocks data, then you are not a real DBA. If you don't know how to analyze execution plans and take corrective action, then you are not an real T-SQL developer. You simply can't perform the job at the level that high-end employers expect.

With databases getting ever larger as a result of things like IoT and data analytics, the bar will be raised for the level of expertise that employers expect from a DBA. You'll be expected to architect database that can scale gacefully to multiple terrabytes, both on premisis and in the cloud. You'll be expected to have expertise in things like dimensional modeling, ETL, and continuous integration. That's what high-end employers expect from a SQL Server DBA or developer today.

Going forward, I expect relational database architecture (ie: SQL Server) to still be very relevent. They'll continue performing the same role they have today, serving as the back end data store for CRM, financial, and line of business applications. For years now, it's been common for SQL Server to work in conjunction with NoSQL databases like Hadoop or MongoDB. The crazy stuff people may have asked you to do with SQL Server in the past (ie: logging telemetry data from devices or persisting the session state for websites) will be offloaded to a NoSQL database solution that's more specialized for that data storage/retreival use case. Over time SQL Server will adapt many of the features found in NoSQL databases (ie: federated partitions across multiple data servers, in-memory databases, and non-transacted bulk loading), and "NoSQL" databases will become more like SQL Server (ie: SQL instead of MapReduce and transacted DML operations). SQL is simply a relational abstraction layer stacked on top of a storage engine; it's been proven as the most popular method of how users want and need to query databases, any database, even "NoSQL" databases. So your investment in knowing the SQL language is still valuable, even if you eventually move to a different database platform.