There is definitely object-relational impedance. I had to deal with this for years on a product that kept its data on a database but was OO when it ran.
As a vastly simplified example, consider three DB tables. Two are just lists, one containing people and one containing jobs. The third is a link between people and jobs, with a column for each. (And all three have lots of columns for lots of subsidiary data.)
In the UI, a user wants to look at the data in terms of a job and the people working on it. A look at the DB, if it's large, is going to be worthless--too much disorganized info. But in the UI, a job object can serve as the basis for good display. Even if the user has a list of a million jobs, he can scroll to the one he wants and see all the relevant info: who's working on it and when and how hard and with what skills, etc.
So on the DB you have 3 tables. In the OO program, you have job objects, people objects and the links between them. The jobs and people lists relate directly to the DB tables, but there is no list of links. The links are part of, or at any rate tied to, the job objects. To create a link table from the OO data, you have to work through all the jobs. To create a proper jobs object, you have to read through the link table and do some awkward rearranging of data.
This is the essence of the impedance. This example is simple in order to be easily understood, but it drastically understates the real-world difficulty in translating between the two concepts.
OO is much faster. It's easier to use once it has been set up. However, it forces a certain organization on the data. If this organization is not done right, or is not adequate, there can be trouble. For instance, in my example the key object is the job. If you want to know what work an individual is doing, it's no good. In this simple example, it is obvious that there needs to be a people object that contains all the work a person is doing, but in a real system the number of possible structures will approach infinity; you have to choose to do that limited number that will let the program do its job.
OO bogs when the random-access aspect of memory becomes slow. OO depends on a lot of direct links between bits of data. How is a large OO database supposed to work? A Document Database makes more sense, but it will either have to really be an OO DB or duplicate vast quantities of data: note that a job object includes people objects, and those people objects include the job object.
Relational data is much slower, but it is without prejudices. A bit of SQL and you can look at the data any way you want. The other, overwhelming, advantage it has is that slow, not-so-random memory--which will bring OO to a halt--doesn't bother it. So if you have terrabytes of data, you want your data stored relationally, not object-orientedly.
So I think we're stuck with relational databases and object-oriented programs and doing a lot of gyrations to get data from the one to the other and back again.
Also: I have recently done some work on a system that uses in-memory relational data. It is very slow, but not so slow as to be seriously annoying (it's not a computer game!) and the original developers, while they had to design a DB, got to skip worrying about an OO design. I considered OO'ing a bit of it, but that meant a lot of programming versus writing just a bit of fancy SQL (LINQ, actually). It clued me in that relational could sometimes compete with OO on its own turf.
It also points out that OO forces organization on the data. If the original developers had known what I needed to do and used OO to do it, the program would have run faster and I could have modified it with a lot less effort. (SQL is tricky.) But if they hadn't OO'ed it they way I needed it done, I'd have been right where I was but without the in-memory relational DB.
Summary: OO and relational are two different things, and converting between them involves impedance--it's a pain. Each has its uses, and I think we're often going to be stuck using both.