Olery成立於2010年，總部位於阿姆斯特丹。該初創公司為酒店行業提供聲譽管理與媒體監控工具，幫助酒店將網絡評論和社交媒體反饋轉化成可執行的商業智能分析。
Olery成立最初是使用MySQL來存儲(用戶、合同等等)核心數據，用MongoDB來存儲評論及其類似的數據(即哪些在數據丟失的情況下很容易恢復的數據)。一開始，這樣的安裝運行的非常好，然而，隨著公司的成長，開始遇到了各種各樣的問題，尤其是MongoDB的問題居多。其中一些問題是由於應用與數據庫的交互方式而引起的，一些則是由數據庫本身而產生的。
例如，某個時刻，Olery需要從MongoDB中刪除一百萬個文檔，以後再把這些數據重新插入到MongoDB裡。這樣的處理方法使得整個數據庫幾乎要被鎖定數個小時，自然服務性能就會降低。而且直到對數據庫執行修復(即在 MongoDB上執行repairDatabase命令)後才會解鎖。而且完成修復還要花費數個小時，修復所花的小時數要根據數據庫的大小來確定。
在另一實例中Olery注意到應用程序的性能降低和設法跟蹤到的 MongoDB 集群。然而，經過進一步檢查，無法找到問題的真正原因。無論怎麼安裝，或使用什麼工具敲了什麼命令都找不到原因。直到Olery更換了集群的初選，性能才恢復正常。
這只是兩個例子，Olery已經有過許多這樣的情況。這個問題的核心是，這不只數據庫在運行，而且無論何時察看它都沒有絕對的跡象表明是什麼原因導致的問題。
無模式的問題
另外，Olery面對的核心問題是mongoDB的重要特征之一：模式的缺乏。模式的缺乏可能聽起來是有趣的，並且在一些情況下是有好處的。然而，對於許多無模式存儲引擎的用法，其導致了一些模式之間的內部問題。這些模式沒有通過存儲引擎定義而是通過應用的行為及其可能的需要而定義的。
例如：你可能有一頁存儲你的應用需要的字符串類型的title字段的集合。這兒這個模式是非常符合當前情形的，即使它沒有被明確的定義。但如果這個數據結果改變超時，尤其是如果原來的數據沒有被遷移到新的數據結構，這就成了問題(在一些無模式的存儲引擎上是相當有問題的)。例如，你可能有下面這樣的 Ruby代碼：
- post_slug = post.title.downcase.gsub(/\W+/, '-')
這樣，針對每一個有“title”字段並返回一個String的文檔，它都能正常工作。然而，對於那些使用不同字段名字(例如：post_title)或者根本沒有標題字段的文檔來說，它將不能正常工作。為了處理這種情況，你需要將代碼調整為下面內容：
- if post.title
- post_slug = post.title.downcase.gsub(/\W+/, '-')
- else
- # ...
- end
另一種處理方法是，在你的模型中定義一個模式。例如 Mongoid，一個流行的針對Ruby的MongoDB ODM，就能讓你做到這一點。然而，當使用這些工具定義一個模式時，你可能會好奇為什麼它們不在數據庫內定義該模式。實際上，這樣做可以解決另一個問題：可重用性。如果你只有一個應用程序，那麼在代碼中定義模式並不是什麼大問題。然而，如果你有許多應用程序的話，這將很快會成為一個大麻煩。
無模式存儲引擎希望通過刪除對模式的限制的方式，讓你的工作變得更簡單。但現實的情況是，確保數據一致性的責任推到了用戶自己的身上。有時候無模式引擎可以工作，但我打賭，更多的時候是事與願違。
好數據庫的需求
有了更多的特殊需求後，迫使Olery尋求一款更好的數據庫來解決問題。對於系統，特別是數據庫，Olery非常注重以下幾點:
一致性是重要的在於它有助於幫助Olery對系統設定明確的期望。如果數據總是按照同樣的方式存儲，那麼系統可以很方便的使用這些數據。如果在數據庫層面要求表的莫一列必須存在，那麼在應用層面就不用檢查這列數據是否存在。數據庫即使實在高壓情況下，也必須保證每一次操作的完整性。沒有什麼事情比單純的插入數據，過了幾分鐘後卻找不到數據的事更讓人沮喪了。
可見性包含了兩點：系統本身以及從中獲取數據的容易程度。如果一個系統出錯那麼應該易於調試。反過來，用戶應很容易查到想要查詢的數據。
正確性是指系統的行為如Olery所期望的那樣。如果某個字段定義為一個數值型，沒有人可以像其中插入文本。這方面MySQL是臭名昭著，一旦你這樣做你將得到偽結果。
可擴展性不僅針對性能而言，而且也涉及財務方面和系統能夠多麼好地應對不斷變化的需求。一個系統在沒有大量資金成本或減緩系統所依賴的開發周期情況下，很難表現得非常好。
