# Fibery End Game (product company example)

**URL:** <https://community.fibery.io/t/fibery-end-game-product-company-example/2830>\
**Category:** Second Brain for Teams\
**Created:** [May 20, 2022, 8:11am UTC](https://community.fibery.io/t/fibery-end-game-product-company-example/2830 "2022-05-20T08:11:52Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\
**Post date:** [May 24, 2022, 7:04am UTC](https://community.fibery.io/t/fibery-end-game-product-company-example/2830/5 "2022-05-24T07:04:11Z")

</div>

We prototyped Fibery on Graph database in 2017 and it was not good for our cases. It is extremely hard to create a performant solution for more than 10K entities if you need Types (and in Fibery everything is around Types). It is close to impossible to have Views like Board, etc with just GraphDB. We decided to went with Postgres and for our main cases it was a good idea, we are happy with the solution.

We are working on GraphQL API that will simplify querying, but this is not a Graph DB for sure.

I want to hear your desired cases, what you need to achieve in Fibery but can’t? Since we are speaking about solution now (Graph DB) and not about problems. Maybe these problems can be solved differently.

We **might** add Graph DB for some specific scenarios, like support bi-directional weak links better (Option 1 in your list I suppose), but we should dig into problems before that to understand the use cases.

---

_[View the full topic](https://community.fibery.io/t/fibery-end-game-product-company-example/2830)._