Channel Explained: Federated databases

Learn about federated databases in this Channel Explained video with Stephen J. Bigelow, senior technology writer. He explains the technology behind federated databases and answers these common questions about the technology:

  • What is a federated database?
  • What's the difference between heterogeneous and homogeneous federated database systems?
  • What are the pros and cons of database federation?

The information in this video will help you talk to your customers that are considering moving to federated databases.

More on federated databases
What is a federated database?
Accessing federated databases with application server components

Read the full transcript from this video below:

Channel Explained: Federated databases

Hi there. I’m Steve Bigelow, senior technology writer with TechTarget’s Data Center and Virtualization Media Group. I’m here today to talk a bit about federated databases. The best place to start is with a definition of federation. For our purposes, federation is a means of integrating different databases across an organization so that they interoperate as if they were one continuous database. It’s similar in principle, in some ways, to storage virtualization; the same way that you can take storage from different storage systems in the organization and pool those resources together and use them, you can do a similar thing with databases by taking them, pulling them together, even though they remain totally complete and separate database applications in the enterprise. Databases for federation are usually linked together with a LAN, usually in the data center. For distributed organizations or for groups of organizations working together, you can easily find federation occurring across a LAN.

Federated databases can be heterogeneous or homogeneous. A heterogeneous federated database … is probably the most familiar approach to a lot of viewers out there. Variety of different, otherwise unrelated, databases are bought together and can be searched as if they were one collective database. It gives organizations a way to conduct searches in a unified way with a minimum of muss and fuss. Instead of having to go to a variety of individual databases, one application can query all the members of the federation, gather those results and return those results back to the querying application, pretty seamlessly in a lot of cases. Homogeneous databases are a bit different in federation, because what you’re doing there is creating repetitive incidences of the same database application. The only difference is that each member of homogeneous federated database has a different portion of the database’s data. What that allows you to do is take a query application, which will only ping the database server that contains the specific pieces of data that you’re looking for, rather than ping all of the databases in the group. What that allows is much more efficiency, a lot faster performance with the same database and, again, all of the members of the group are operating independently. SQL Server 2000 or later has a function that mimics homogeneous database federation.

The problem that you run into with homogeneous federation is that the query has to be phrased properly and the data in each database member has to be segregated properly so that a query doesn’t cause multiple pings. Otherwise, you have multiple hits to multiple databases simultaneously, and that overcomes the performance benefit of the homogeneous federation.

There are some pros and cons that you need to consider when it comes to database federation. Of course, the biggest advantage is convenience; it allows organizations to search a large number of databases simultaneously and collect a lot of information without having to create or merge databases together, which can really be an arduous process. The key to federated databases working properly is the application that you’re searching with. The application has to be able to accept your query, it has to be able to parse the query properly and send the appropriate sub-queries to the members of the federated group. The application then has to take all of those responses, which could be very different depending on which database you’re actually working with, and combine all those results together into a unified response; it has to cobble all that information together. That’s a challenge for applications in this part of the industry right now, but something that should certainly improve as time goes on and the technology sees greater use. There are some other aspects of maintenance: Each member of the federated group is a potential single point of failure. Organizations that are sensitive to high availability or need to make sure that federated database requests are always available are going to need to implement high-availability strategies for their various database servers. There’s also a consideration of maintenance: Since each database in the group is potentially owned and operated individually, each has to be maintained and upgraded on a very well-coordinated approach; otherwise, you risk interoperability and performance problems that can really have an adverse impact on your federated data effort.

That’s my nutshell view of federated databases. I want to thank you all for watching. I’m Steve Bigelow, senior technology writer with TechTarget’s Data Center and Virtualization Media Group. You can learn more about federated databases at

View All Videos