MongoDB or Postgres?

Did you decide to go with Mongo over Postgres? I saw here that it says MongoDB, but I wasn’t sure if that was just old or if you switched back?

1 Like

We first went with Postgres because we thought we would save the data on disk space and get better performance since most of our data is relational. During the testing phase, we realized that Postgres didn’t give us any benefits. It was difficult for users to run it as updates frequently required data or schema migrations.

MongoDB contacted us while we were in the development phase, and we had a few calls with their engineers. They showed us some cool features in their cloud platform that we weren’t aware of. For example, in their cloud, you can set it to archive historical data automatically, and you can query both fresh and historical data over a unified API.

This feature makes a lot of sense for our network; we can automatically put historical signatures in cold storage, and the newer ones that are more frequently accessed and need verification will be in hot storage, reducing the costs considerably.

Ultimately, we decided to be DB-agnostic with primary support for MongoDB. Currently, the network implements an interface for database operations and implements both Postgres and MongoDB support. With TEP-3, we will remove Postgres from the code base, and in the future, we will move MongoDB support from the core to a plugin. Users can already write their plugins in any language and use any DB they want.

2 Likes

Thanks for the detailed response, Pouya.