you are correct. In this case, we can imagine that ESRI is part of the stack. You might have a Department with SQLServer, one with Oracle, and one with PostgreSQL. In my original video, you can see how Radian can work among them seamlessly.
So now, imagine that you have ESRI inside of that stack. Here we had a geodatabase (a true file geodatabase, not a personal geodatabase that uses a .mdb file). You can then use Radian to read the data and perform processing on the file - using Radian.
Imagine you have a function you need to run over, and over, and over again (i.e. find all the different soil types that make up a parcel). In this case, you can use the SQL in Radian to dump that off. Your organization can still be an ESRI shop, making use of all the ArcGIS goodness you like. But, with Radian, you can also tap into that database.
And here is the cool part - like my first video, you can grab data out of a geodatabase and put it in Oracle, SQLServer, PostgreSQL, SQLite, etc. So, Radian becomes a nice bridge to all these databases, like a true ETL package. I think that there will likely be a large number of people who might just want Radian as an ETL tool.
I have a project that I am about to start up with a student where we are going to use Radian in this manner for a local municipality with a heterogeneous IT system. The goal is for Radian to grab stuff from everywhere and just get answers to questions that the municipality wants. It will be the first time they can tie their disparate infrastructure together. I'm looking forward to seeing how it goes, and I'll blog about it when we get started.
*p.s. in this case, Radian does not work 1000x faster than ArcGIS. I haven't done the timings. I will do some multicore stuff later today and report back. The main goal was to work with the architecture of the thing. I'll monkey around with some other processes later (both multicore and GPU) and see what happens. I don't anticipate HUGE differences for vector stuff, but with raster, who knows.