Live data from Hacker News

FerretDB: open-source MongoDB alternative

blog.ferretdb.io

101–110 of 130 posts

Re: FerretDB: open-source MongoDB alternative

#101

Earlier quoted context omitted.

Joins only make sense in analytical context as a tool to get some additional data into your report and almost never as domain modeling concept. People should pretty much hardly ever use RDBMS for their domain data... but since everyone learns RDBMS as their first DB, we have these horrible ORM frameworks on every corner.

Curious why you think this? I've found Relational databases pretty powerful, and learned mongo first.

They are powerful. But often their Power is unnecessary and counter productive for domain modeling.

Where are they really good is reporting. Analysts love rdbms. When I am on an analyst role, I love them them too. As an engineer I find them redundant.

More about domain modeling

https://dev.tasubo.com/2022/07/crash-course-domain-driven-de...

Re: FerretDB: open-source MongoDB alternative

#102
post #33

If it can run a replica set on an apple m1 which mongo can’t currently do then great!

Er, why can’t you run a MongoDB replica set on your M1? I mean, I wouldn’t recommend running a ReplicaSet on the same host on any production host (it defeats the purpose), but for testing, I’ve run a sharded cluster w/ 3 replicas per shard… Happy to try and help!

Can you send me an email? Julien at/ serpapi.com

Re: FerretDB: open-source MongoDB alternative

#104
post #58
post #35

Earlier quoted context omitted.

Er, if you develop the infrastructure to host MongoDB, you should absolutely be able to open-source that infrastructure. I mean, before MongoDB, I wrote a cluster management system for virtualized software security and hypervisor research, and all of it was either open source or something I wrote… Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license? Your s…

> Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license? Lets say you are running your infra on any cloud provider. Do you think its realistic to get them to hand out their source code?

The cloud provider wouldn’t have to, if you are the one running your infra. The SSPL restrictions only apply to businesses that offer MongoDB as a service.

In fact, you can build a similar service and offer it within your organization (and subsidiaries), and you still don’t have to release anything. The license only applies to companies like Amazon if they offer MongoDB as their own service (DocumentDB).

I know that’s a bit tangential, but hope that helps a bit?

Re: FerretDB: open-source MongoDB alternative

#105
post #97

Earlier quoted context omitted.

Those aren’t listed are they? The idea you need to release code for the os, file system, network routers, etc is absurd.

Let's say you bought that storage system: https://www.dell.com/en-us/dt/storage/powerstore-storage-app... AFAIK, it doesn't come with complete source code, and you could not request all of it. Let's say you decided to run MongoDB as a service, and you are fine with releasing Service Source Code under SSPL. The problem is – you can't. You don't own the source code for your NAS and can't relicense it. Nothing in the te…

Er, I could be wrong, but I think you’re missing the scope set in the first sentence:

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the… SNIP …programs that you use to make the Program or modified version available as a service…

I’m eliding for clarity, but the NAS doesn’t make the program available as a service. The code that accesses the file system on the NAS to offer your service? Probably need to release code that calls fread/fwrite/NtFileX in your infrastructure code.

I get that it sounds vague and everything, but the FAQ also clarifies none of this applies unless you’re competing and targeting third parties. If you’re one of the few companies who want to do that, your legal team can formalize the line of demarcation.

Apologies, I hate defending the SSPL, but I can’t think of any better way to stop the monopolistic and EEE practices against open source projects. If anyone has a better solution to protect the freedoms of open-source developers, please, please publish it!

Re: FerretDB: open-source MongoDB alternative

#106

Earlier quoted context omitted.

FerretDB maintainer here: we are working on it. We are already getting reports of successful migrations with Meteor apps. [1] Would you mind sharing the specific Meteor app you are looking to get supported? MeteorJS is among the most requested applications/frameworks our users are looking to use with FerretDB. [1]: https://twitter.com/CowboyCaramel/status/1646089964126347264

I'm a contributor to the Sandstorm.io project, and Mongo continues to present a bit of a pickle for us. We can arguably write our way out of one upgrade, but upgrading to a later Mongo just punts the issue again. We'd much rather just leave Mongo behind.

What kind of problems does mongo cause for sandstorm that postgres does not?

Re: FerretDB: open-source MongoDB alternative

#107
post #42

Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit? At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret. Today,…

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-co…

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

What's the alternative you want to move to?

Re: FerretDB: open-source MongoDB alternative

#108
post #61

Earlier quoted context omitted.

Those aren’t listed are they? The idea you need to release code for the os, file system, network routers, etc is absurd.

SSPL license text doesn't set any limits on the scope for source release. Verbatim quote: > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation…

I think “including, without limitation, […]” applies to the breadth of components, not depth, right? I mean, I’m not a lawyer, but that seems to be what syntactic context and logic indicate… no?

If you disagree, could you indicate the relevant text?

Re: FerretDB: open-source MongoDB alternative

#109

Earlier quoted context omitted.

I'm a contributor to the Sandstorm.io project, and Mongo continues to present a bit of a pickle for us. We can arguably write our way out of one upgrade, but upgrading to a later Mongo just punts the issue again. We'd much rather just leave Mongo behind.

What kind of problems does mongo cause for sandstorm that postgres does not?

The core of the issue is Mongo does not seem intended to be upgraded reliably without intervention. Sandstorm is running on thousands of servers where the admins aren't equipped to handle Mongo upgrade issues, as well as within some Sandstorm apps which also use Mongo inside containers not intended to be user servicable.

One of the issues we hit is here: https://github.com/meteor/meteor/issues/11666 in which if you happened to have a Mongo database over eight years old (many Sandstorm servers have been deployed for that long!), you needed manual intervention to correct it, even if you had done intermediate version updates in between.

Meteor patched around this issue... but after dropping support for several releases of Mongo. So we essentially need to build our own automation which understands and can export old Mongo databases, and then import new Mongo databases, while shipping a Meteor app that can only run on one or the other, which has to auto-update smoothly, and recover from failure like if there isn't hard drive space to handle the process.

And then we also need to implement that within app sandboxes which can also arbitrarily terminate so that also has to recover well and we need to ship the logic to do this with every Mongo-backed app package until the end of time.

Re: FerretDB: open-source MongoDB alternative

#110
post #21

Earlier quoted context omitted.

The only problem I have with PostgreSQL's JSONB type is it strictly implements the JSON standard, so things like nulls and integers aren't supported. Depending on your data, this could be a real problem.

FWIW, JSONB supports JSON nulls, and all numbers are encoded as `numeric` type, storing integers and float64 values precisely (well, as much as possible for float64 values). But you comment is correct for other data types like date-times and binary strings where some form of encoding/decoding is needed.

Yeah, I was misremembering. Our issues were related to NaNs, which we ended up encoding as nulls. I don't think we've had issues with dates yet.
Post reply on HN