2012年秋季Facebook啟動了Presto，Presto的目的是在幾百PB級別數據量上面進行准實時分析。在摒棄了一些外部項目以后，Facebook准備開發他們自己的分布式查詢引擎。Presto的語法基於ANSI SQL，大多數分布式查詢引擎需要用戶去學習一種新的語法，有的語法類似SQL，但是沒有一種是和真正的SQL一樣被人們所熟悉，並且有詳盡的文檔。Facebook希望這個決定能夠使得培訓新用戶變得更容易更快速。依賴於 ANSI SQL也讓Presto能夠利用的現存的第三方工具。
在內部， Presto基於流水線。當請求被分析，任務分配到適當節點以后，客戶端從輸出階段拉取數據，輸出階段從更底層階段里面拉取數據。Presto的執行模式是和Hive/MapReduce有着基礎性的差異的。Hive把查詢語句翻譯為MapReduce任務的不同階段，然后一個接着一個的執行。每個任務從磁盤讀取輸入，然后把中間結果寫回到磁盤中。與之相反的是，Presto不是使用MapReduce，他使用大家所習慣的查詢和執行引擎，它們有着設計好的支持SQL語法的操作符。比優化過的調度更進一步的是，全部處理過程都是在內存中，而且是在不同階段之間通過網絡交互進行流水線作業的。這規避了不必要的IO操作，和隨之造成的過高的延遲。這種流水線化的執行模型可以在同一時間內運行不同的階段，當數據可用以后，流數據就從一個階段到另外一個階段。對於很多類型查詢來說，這就顯著的減少了端到端的延遲。
Presto是使用Java寫的一個可插拔的后端。對於很多數據源來說，例如Hive、Hbase或者Scribe，就需要一個數據連接器。這個連接器為Presto提供元數據、那些節點保持數據的信息，還提供了一種把數據當做流的辦法。
在Facebook絕大多數查詢場景中，Presto在時間消耗和cpu占用上面超過Hive/MapReduce十倍。Facebook仍然計划去進一步提升性能。一個計划是設計一種新的數據格式以減少當數據從一個階段到另外一個階段時候所需的數據轉換量。Facebook還計划去掉一些目前設計中的限制：目前最主要的限制是join操作時候表的大小和unique 主鍵和group時候的基數的大小。目前系統缺乏把輸出數據協會到表的能力，目前查詢結果是回流到客戶端的。
國內目前美團有大規模使用，見：http://tech.meituan.com/presto.html
目前Presto已經納入到apache2.0中，其git地址：https://github.com/prestodb/presto
官方文檔：https://prestodb.io/docs/current/overview/use-cases.html