FerretDB: open-source MongoDB alternative

Post by aleksi » Thu, Apr 13, 2023, 8:08 PM UTC

that_guy_iain wrote: post #120

aleksi wrote: post #99

Earlier quoted context omitted.

> AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels. AGPL requirements do not trigger if you don't modify the source code. The relevant text is in section 13: > […] if you modify the Program, your modified version must prominently offer all users […] See also [1], [2], [3]. > “Program as a Service” seems a lot more limited in scope. AGPL scope: > The "Corresp…

> As noted in another thread, that's not only beyond the scope of the software itself – it is beyond the scope you _can_ relicense and arguably beyond the scope of the copyright terms themselves. This is not true. People who are saying this would have said this about GPL when it first came out.

Post by nextaccountic » Fri, Apr 14, 2023, 5:19 PM UTC

deepsun wrote: post #7

At one company we had one-off requests to run get some statistics from our mongodb. Writing the proper queries proven pretty tricky whenever GROUP BY/JOINs were involved, so I used online converters between SQL -> mongo query. But then I realized that PostgreSQL has nice JSONB type (supports indices for subfields). So I put all the mongo data into tables with a single JSONB column (or two columns id+data, if you pref…

Post by afiori » Fri, Apr 14, 2023, 8:58 PM UTC

forgetfulness wrote: post #25

skatanski wrote: post #13

Earlier quoted context omitted.

If there were JOINs it may be a sign MongoDB was not the best DB for you. It means the model was relational and a relational DB would be a better fit. MongoDB lookups are discouraged in general, and especially in analytical workloads, which cover a lot of data. MongoDB is better for the scenario, where all you need is already in the document.

Should it be used as a database in the way that Postgres would be used as a database? It seems pretty unfit for that role, with its past durability issues and that writes have to be tailored to how the data will be consumed, due to lack of ad-hoc queries. As something layered on top of the actual source of truth it may be reasonable, writing a materialized version of a costly query that's read very often, sure, but t…

Post by aleksi » Sat, Apr 15, 2023, 5:32 PM UTC

nextaccountic wrote: post #126

peterfarkas wrote: post #124

Earlier quoted context omitted.

Yes, building an extension is something we are looking at, and I am glad to hear that you would be interested in this kind of mixed use case. Would definitely make things interesting, and more performant.

Pretty exciting! What about optionally validating some columns with jsonschema? Perhaps using https://github.com/supabase/pg_jsonschema - is using other postgres extensions supported in FerretDB? (if not, maybe it's feasible to incorporate the code of pg_jsonschema in FerretDB?)

Post by mgfist » Sun, Apr 16, 2023, 1:14 AM UTC

skatanski wrote: post #37

mgfist wrote: post #19

Earlier quoted context omitted.

It may also mean poor schema design. You can absolutely model relational data in MongoDB without relying on joins. If you want to normalize your data don't pick Mongo.

agreed, you can have reference fields to other collections and filter by them or query related data. But I wouldn't say its designed for relational workloads. Similarly I wouldn't use MongoDB for graph queries, even though it has an operator for just that.