Comment by peterfarkas | Hacker News Reader

Comment by peterfarkas | Hacker News Reader

Parent Full thread

Yes, FerretDB is a layer which implements the MongoDB wire protocol on top of Postgres. Right now we are using JSONB, but this affects performance and we need to depart from this strategy in the long run. We have an article which explains the concept [1].

I wouldn't go into the document vs. relational argument, all arguments for and against would have merit. There are valid use cases for document databases (take e-commerce, for example), and we should not discount the fact that using a relational database is just more complicated. Using vanilla Postgres for a MongoDB use case will not be feasible for someone who's focus is, let's say, mobile application development. There is a reason behind MongoDB's popularity - it just provides a great developer experience. This is what we are aiming to recreate on top of Postgres.

[1]: https://blog.ferretdb.io/pjson-how-to-store-bson-in-jsonb/

if we use Ferret for prototyping and eventually land on a schema, would it be possible to convert the FerretDB rows into more structured postgres? Would be so cool if it could just analyze and create a schema for you, you double check it, and it just works.

I think being able to convert back and forth would make it so worthwhile!

Yeah, we want to do that: https://github.com/FerretDB/FerretDB/issues/226

I'm curious about what makes document databases a good fit for e-commerce. I've never worked in that industry.

Two things off the top of my head:

1. Denormalized data is often a boon. One of your key use cases is "give me all the information about this Product so I can show it to the user." Forget joining a ton of tables, just do 1 read of 1 product and go on your way.

2. A certain amount of more freeform data is expected. Different product categories will have different sets of information. T-shirts and drinkware both have sizes, but these sizes have nothing to do with each other. You can model all this in a traditional SQL database, but you have to stop and think really hard about it, and potentially end up with a plethora of tables. In a document database, it's much easier to just add the data and go on your way.

That makes a lot of sense, thanks!

> we need to depart from this strategy in the long run

What's the alternative you want to move to?

Probably a custom PostgreSQL extension for BSON support.

The biggest issue right now is that MongoDB compares and sorts values differently than PostgreSQL/jsonb. For that reason, we have to do a lot of filtering on the FerretDB side, and that can't be great for performance. Pushing more work on the database size should make FerretDB perform much better.

Reply on news.ycombinator.com