This page lists the identified improvements that might be present in some future version of the product.

1. Multi-tuple records. Such a feature would make it possible for a dba to define a single record that can hold (data from) tuples of multiple distinct relvars. One can then define a logical model in 6NF for some application (with e.g. 50 relvars holding each one customer attribute/property), and instruct SIRA_PRISE to store only one record per customer with all 50 attributes combined, including all necessary incidators to manage the absence of (one or more tuples holding a value for) some of the attributes in the record. In yet other words, it is about allowing the storage of tuple records that are "remarkably resemblant" to the "outer join" of the tuples concerned.
2. Improve data access strategies. Quite a bit of attention has already been given to the subject of optimising data access strategies, but this work is of course never final and complete. Technical improvements such as multi-threaded evaluation of e.g. nested expressions, are still completely absent.
3. Complete the set of supported relational operators. Operators such as generalized transitive closure and TTM's summarize (as opposed to summarizeby) are not yet operational.
4. External transaction monitors. Transactions involving the SIRA_PRISE server are controlled at the client level. The facilities needed to incorporate the operation of SIRA_PRISE into a transaction that is controlled by an external software component are not yet present, however. Allowing this will involve, a.o., supporting two-phase commit in line with some commonly used protocol.
5. Distributed databases. SIRA_PRISE has no facilities that allow multiple servers to form a "server complex" and act to the outside world as if they were one single server engine. Such a feature will also require two-phase commit to be supported.
6. Database statistics. Collection of database statistics is still quite rudimentary. Significant extensions and/or improvements may be possible.
7. Extend database management functionality. Quite a number of database management operations are still unsupported (e.g. moving an index to a different physical location). Allthough in practice, bypasses are normally available to circumvent the problem (e.g. define an additional index in the desired location, and then drop the old one), this means that the job of database administration may have an "uncomfortable feel" over it, and users might like support for database management (or "database administration" if you prefer that term) to be lifted to a more acceptable level.
8. Various refinements in the catalog. A concept of "attribute aliases" is missing, which somewhat aggravates the workload in defining all required attributes. E.g. often relvars must be defined which establish a "parent-child" or "bill-of-material" relationship between two occurences/appearances of something. Such relvars typically contain two attributes of the same nature, and from the perspective of "business analysis", it is often desirable to think of these two attributes as being "the same business element" (e.g. the identification number of a customer). Nevertheless, SIRA_PRISE does not allow the creation of such relvars unless two distinct attributes have been defined in the catalog. Including a concept of "business element" and "element alias" (or "attribute alias") might alleviate this.
9. Quota queries. No support is currently present to allow the user to specify queries of the general nature "give me the first ... tuples of ... ordered by ...".
10. Complete support for the concept of constrained types : automatically define the corresponding interval type if applicable, etc. etc.
11. MVCC-based "Snapshot isolation" support.
12. Support for exploiting the journals for reporting purposes.
13. Slightly improved way to specify "same-as-this-relvar" headings in relation literals. Current syntax gives problems if a relvar has the same name as an operator (e.g. ROUND). These problems are avoided in the -slightly longer- syntax RELATION(HEADING(<relvar>)BODY(...))