We found a small issue affecting some Vector Search queries that may lead to a runtime error when your vector search query uses aliases to shorten or disambiguate table names. The problem can be worked around by rewriting your query to avoid using aliases. A fix for this issue will be included in the next preview kit, due in two weeks.
We also identified a separate issue with unintended changes to DSTIME behaviour, and recommend DSTIME users to skip this preview. The next preview kit will restore the original DSTIME behaviour.
I got completely distracted by this article's use of "Dynamic SQL". Dynamic SQL is a fairly specific concept on our platform, and historically there's been a small difference between Dynamic and Embedded SQL in terms of overhead, but that has all but evaporated over the past few years by consecutive optimizations. Now suddenly this article seems to suggest there's a huge gap, so I got hooked and dug into the code, only to find that this method is making a rather crazy detour through %DynamicObject for no real reason, on the way from the SQL result set to the dataframe. In other words, all you're measuring between the "Dynamic SQL" and "IRIS SQL" options is exactly that %DynamicObject overhead.
It's only a name, true, but people only doing a cursory read of the article may take away the completely wrong thing.
extended is not the same as unlimited :-)
We're moving from 32-bit block numbers to 40-bit block numbers, which means the max size for a database with 8k block size is 8PB. Obviously, those are huge amounts of data, and we strongly recommend against just stashing that all in a single IRIS.DAT file,, if your file system permits such files at all. Multivolume database support already helps you spread data across multiple physical files (opaquely), and the new Table Partitioning support (experimental in 2026.1) helps you spread table data across multiple databases.
If you wonder why we stuck with 40 bit numbers rather than a power of 2: we were able to reuse a few available bits in the current block header format, meaning you can transparently and instantly upgrade to this Extended Database Format without having to migrate your almost-32TB database to a new block header format. And 8PB is quite large already...