I've always gone with the rule of 1 Broker per website, the main reasons being for most efficient CCS, cleaner deploying set up, separation of concerns if one 'goes down' etc

We have a new implementation and 3 main websites, where all content is being published to the DB using the DD4T framework.

A new requirement is that the websites will need to use content and component links from each others publications. The team here is going with the rule 'we'll put all sites in the same broker db'

I don't like this idea, but the content was originally not intended to be shared across the multiple sites and the mvc views are not stored in a correct structure to allow easy consumption from the other site so to do this 'my way' would require some extensive last minute development.

The 'my way' solution would be to have the content stored in separate broker database and:

  • Use odata to pull the content we need from each others site
  • Write our own logic where we need to pull specific content

I wanted to open this scenario up to the community to see what people's thoughts are, if anyone has encountered a similar situation, or worse gone down the route of a 'single' broker and what issues they have ran into further down the line, what has been done to ensure performance, uptime and is not an issue.

Thanks, John

  • 2
    your way is hella complicated John, with Odata and all ;) Back in pre-Tridion 2011 days when OData wasn't available this would have required building a custom web service, when all we need is to have less moving parts (i.e. less DBs and less custom code) to accomplish the same. Commented May 9, 2013 at 15:58
  • 1
    I've seen the fun side effect of one CD broker killing performance on all applications using the same database. On a DEV setup where CM and CD share a database, a bad criteria filter query could potentially even kill CM performance. Be sure to test your filters. :-) Commented May 9, 2013 at 16:51
  • Hi John. I might miss something but I need to ask: why do you need the content to be in one DB? You will still have 1 Broker per website but just that the Broker needs to be aware of the 3 DB's. I assume that each website has a publication behind so all you need to do is keep it as it is but also properly define the db's and the publications inside each cd_storage_conf.xml Commented May 15, 2013 at 22:19

3 Answers 3


We have worked on a Platform (very much famous and has been featured in many of SDL Tridion Shows as a case study) where we had more than 80 websites sharing data from same broker. And this has been implemented in SDL Tridion 2009. The approach was as below:

  1. Any data that needs to be fetched from broker is fetched by using a WCF service based on a specific query which in turn uses the SDL Tridion Content Delivery DLLs - In 2011, you may choose for the Content Delivery Web service (aka ODATA service)
  2. Where ever there is need to show a collection of data (kind of a list page) - we have indexed that in Search Index - SOLR - and fetches it based on scenario by using a WCF service

(so more or less second option in your question)

This approach worked pretty much good with more than 80 website with decent amount of data publishing and across a wide variety of channels - web, iphone native app, blackberry native app and android native app and few more applications ranging from ASP.NET MVC based website to plain ASP.NET applications.

However, since it was a platform and we try to implement it another scenario where the Publishing amount of data is huge (think of half million publishing activities in a span of 2 ~ 4 hours), the performance was terrible. We then took lot of measures like having a separate publishing server, optimizing deployer extension, CTs and many more measure to make it work decently.

I hope it helps.


When you say "1 Broker per website" do you mean per publication or would several language publications of a website share 1 Broker?

At the moment we're running 5 websites (language publications) on DD4T from a single broker - with CCS + DD4Ts caching + ASP.NET Output caching our site(s) are (were!) running pretty well - albeit its not a high demand website.

  • hi neil - yeah i mean one broker db per publication
    – johnwinter
    Commented May 9, 2013 at 17:41

I don't think you should have any concerns about using a broker database for multiple publications. It's clearly designed to support this scenario. In fact, I think you'd have to have a reason not to go with multiple publications per database. So for example if you had publications with different security requirements or something like that. Otherwise, go ahead and use the same database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.