# FDB 7.0 Roadmap **URL:** \ **Category:** Development\ **Created:** [October 2, 2019, 2:54am UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660 "2019-10-02T02:54:02Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [October 2, 2019, 2:54am UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/1 "2019-10-02T02:54:02Z")
Apple and Snowflake folk have been coordinating on the roadmap for the next FDB release (planned to be 7.0), and the document for this has been hiding [on the wiki](https://github.com/apple/foundationdb/wiki/FoundationDB-Release-7.0-Planning) for a little while now. This is neither a promise that the work will make it into the release, nor the only fixes or improvements that will be included, but should outline most of the larger planned features. Anyone see something important to them missing? Excited for anything in particular? ---
**Author:** ![seddonm1](https://avatars.discourse-cdn.com/v4/letter/s/e274bd/32.png) [@seddonm1](https://forums.foundationdb.org/u/seddonm1)\ **Post date:** [October 2, 2019, 10:16am UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/2 "2019-10-02T10:16:11Z")
@alexmiller I think the big win will be the Redwood Storage Engine particularly the prefix-compression and all the benefits that comes with it. It would be great if Steve could describe some of the ‘significant performance improvements for a variety of workloads’ that you have measured - or maybe you are saving it for the summit. Either way sounds good! ---
**Author:** ![gaurav](https://avatars.discourse-cdn.com/v4/letter/g/b487fb/32.png) [@gaurav](https://forums.foundationdb.org/u/gaurav)\ **Post date:** [October 2, 2019, 2:57pm UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/3 "2019-10-02T14:57:07Z")
Hi Alex, are there some preliminary details of what kinds `Predicate pushdown` operators would be available? I want to check the possibility of including a few user-defined server-side operations on version-stamps when forming the row-key/row-values, as discussed [here](https://forums.foundationdb.org/t/possibility-of-server-side-operations-on-versionstamp/1577)? This request is similar to the usage pattern by the FDB backup agent, as described [here](https://forums.foundationdb.org/t/keyspace-partitions-performance/168/4). (PS: 7.0 roadmap looks quite exciting: I started to mention specific items from the list, but figured that almost everything on the list will be very useful 🙂 ) ---
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [October 4, 2019, 2:56am UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/4 "2019-10-04T02:56:49Z")
> [@seddonm1](#): > > It would be great if Steve could describe some of the ‘significant performance improvements for a variety of workloads’ that you have measured - or maybe you are saving it for the summit. It definitely is part of the content slated for @SteavedHams’s summit talk. I’ll let him decide if he’d like to leak content or not. 😛 > [@gaurav](#): > > Are there some preliminary details of what kinds `Predicate pushdown` operators would be available? My current knowledge of @mbhaskar’s plans for the first version of this is to allow selection filters for tuple-encoded keys to be pushed down. e.g. "get\_range(start, end), but also only return all kv-pairs that match `key[3]==0xF00 && key[5]=="bar"`. But he might be able to share more light than I, or promise a future design doc 😉 ---
**Author:** ![mbhaskar](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/mbhaskar/32/277_2.png) [@mbhaskar](https://forums.foundationdb.org/u/mbhaskar)\ **Post date:** [October 4, 2019, 6:09pm UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/5 "2019-10-04T18:09:08Z")
> [@alexmiller](#): > > My current knowledge of @mbhaskar’s plans for the first version of this is to allow selection filters for tuple-encoded keys to be pushed down. e.g. "get\_range(start, end), but also only return all kv-pairs that match `key[3]==0xF00 && key[5]=="bar"` . But he might be able to share more light than I, or promise a future design doc 😉 Yeah, I am in the process of writing down a design doc. Will share it very soon. @gaurav User defined functions on version stamp operations, you were asking for, are in the write path (in Proxy). Scope of Pushdown project we are looking at is pushdowns to storage server only, just in the read path. We are looking into pushdowns of different kinds of user defined functions - Predicate pushdowns, Aggregate pushdowns and Index lookup pushdowns. For the first version of this, we are leaning more towards a well defined language to express predicates or operations. This language gives constructs to build complex expression trees which can be pushed down to storage servers. Hope is this can help many use-cases without compromising security, reliability or portability. ---
**Author:** ![gaurav](https://avatars.discourse-cdn.com/v4/letter/g/b487fb/32.png) [@gaurav](https://forums.foundationdb.org/u/gaurav)\ **Post date:** [October 5, 2019, 2:53am UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/6 "2019-10-05T02:53:01Z")
Thanks for clarifying that; it makes sense! ---
**Author:** ![doublemax](https://avatars.discourse-cdn.com/v4/letter/d/8e7dd6/32.png) [@doublemax](https://forums.foundationdb.org/u/doublemax)\ **Post date:** [January 5, 2020, 1:45pm UTC](https://forums.foundationdb.org/t/fdb-7-0-roadmap/1660/7 "2020-01-05T13:45:03Z")
Looks really exciting - especially the “stable wire protocol”. 😍