No, "using a product" from a vendor is not vendor lock-in. Especially in the case of a product like this, which turns your employees' work product (queries) from "something that works only with Oracle" (as would be the case if you used Oracle's tooling) into "queries that work with potentially any database."
So when your Oracle rep calls and says "bad news, your license costs went up by 150% this year. What are you going to do, switch databases? Hahahaha!" you can reply "well you know, we can actually flip a switch and run on Postgres now. We'll get back to you."
Yeah, it never quite works out that easily in practice. But by using products from a selection of vendors that support other ecosystems than just one, you're reducing your vendor lock-in.
And your risk of finding that all the code you've created using a proprietary tool that runs on top of a proprietary platform owned by another entity is greater than just using the tools provided by the platform vendor who controls "the stack" of software below any other vendor providing an add-on.
Basically, (in this case) Oracle can break 3rd party add-on tools and programs anytime they want or make them operate in a suboptimal way by changing their product below. Oracle, Microsoft and other platform vendors have repeated done this in the past.
So buying cloud based or closed source tools that run on top of other closed source products controlled by another entity is a poor bet.
So when your Oracle rep calls and says "bad news, your license costs went up by 150% this year. What are you going to do, switch databases? Hahahaha!" you can reply "well you know, we can actually flip a switch and run on Postgres now. We'll get back to you."
Yeah, it never quite works out that easily in practice. But by using products from a selection of vendors that support other ecosystems than just one, you're reducing your vendor lock-in.