Skip to main content

Teiid 10 Planning

As we get closer to staring on Teiid 10.x, we want to elicit as much community feedback on our initiatives as possible.  Some of the major themes are:
  • Refining our messaging around and our usage of WildFly TEIID-4895
  • Removal of the XML document model logic TEIID-4894 and other deprecated features
  • Spring Boot TEIID-4863 and eventually vert.x support
  • More documentation and demos around microservices
  • General project updates including 
    • more build automation
    • possibly do away with pre-release names (e.g. Beta1) and instead promote specific micro releases
    • Relicense under a more permissive license TEIID-4474
Of course there's a lot more already in the 10.0 and 10.x release buckets as well.  Please provide whatever feedback you can - especially on WildFly usage.  Also have a look at all of your relevant issues and comment or vote on any that need more immediate inclusion.

Beyond the core project we are in the initial stages of working towards an OpenShift ready data integration suite including:
If you have any desire to coordinate on these additional efforts, please let us know so that we can loop you in once the appropriate git and other resources are in place.



  1. For Teiid 10, can more usability items be prioritized. For example, the difficult to use developer tooling and the requirement to use odjbc postgresql driver for .NET connectivity. I feel those will do more to grow the Teiid community than just adding additional connectivity.

    1. Adil,

      Does Npgsql [1] help with .NET access to Teiid? May be we can fix any incompatibilities with that.



    2. Thank you for your response. I haven't looked into that library myself when I evaluated Red Hat JBoss Data Virtualization. Having Teiid/Red Hat JBoss Data Virtualization have that as the supported and preferred way of connecting from the .NET platform would instill a lot of confidence. I will look into it when I get some free time.


Post a Comment

Popular posts from this blog

Teiid Runtimes Explained

If you have been following Teiid lately we have been going through a whole lot of renovations. Yes, renovations or reorganization or refactoring or whatever you want to call it. Basically, we are making Teiid more modular with fewer dependencies that can be used by however your use case dictates rather than use it as one monolith application deployed into WildFly JEE Application Server. There is nothing wrong in using Teiid as server model, but with the proliferation of container-based workloads and cloud-based architectures, the previous server-based model does not work or simply won't scale. So, we needed to think of alternatives, thus Teiid team introduced a couple different versions modular Teiid what we are calling as "Teiid Runtimes".

Note that in these modular Teiid runtimes, not all the features you were used to using in Teiid Server model may not be there but you will have extensions to add in those that are most appropriate for your domain. If you are looking …

Teiid Platform Sizing Guidelines and Limitations

Users/customers always ask us about the sizing of their Data Virtaulization infrastructure based on Teiid or the JDV product from Redhat. Typically this is very involved question and not a very easy one answer in plain terms. This is due to fact that it involves taking into consideration questions like:
What kind of sources that user is working with? Relational, file, CRM, NoSQL etc.How many sources they are trying to integrate? 10, 20, 100?What are the volumes of data they are working with? 10K, 100K, 1M+?What are the query latency times from the sources? How you are using Teiid to implement the data integration/virtualization solution. What kind of queries that user is executing? Even small federated results may take a lot of server side processing - especially if the plan needs tweaking.Is materializing being used?Is query written in optimal way?and so on..Each and every one of the question affects the performance profoundly, and if you got mixture of those then it become that much…