I emailed the project authors a while back and they said that unfortunately it had been abandoned. A shame. I hope the FerretDB people can pull it off.
Thank you for mentioning this. Unfortunately, yes, ToroDB is no longer being developed. I still believe it's a fantastic idea, and provides significant value. But when it was being built, 5 years ago, the NoSQL (as in "abandon SQL") state of mind was too strong, and the value proposition was not well understood.
I moved to work on what's always been my passion and preference: Postgres, Postgres, Postgres. For those interested, StackGres[1] is what's now my company's focus.
Things may be different today with ToroDB. The technical foundations and ideas are still there. If there would be significant interest by entities that would like to contribute to its development, it could be considered.
I wish good luck to FerretDB. The task ahead is not easy: MongoDB protocol is very simple, but the API is terribly complex and full of nuances. Getting up and running a simple PoC is very simple. Getting from there to a production quality state with notable compatibility is very hard.
I may be mistaken but I think ToroDB never tried to be MongoDB replacement but rather something you use as MongoDB replica to get your data in PostgreSQL so you can query it with SQL for analytical projects ?
The wording in sspl is awkward in its vagueness of its scope, specifically this clause:
> “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 software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available
For example providing SSPL software running on AWS as a service is probably/possibly license infriging because you are not able to provide source code for all the stuff you are using.
In practice probably even the most well-intentioned service provider can easily be trapped by that clause.
I'm wary of it because "make the functionality of the Program or a modified version available to third parties as a service" is vague.
If I have a web app that persists data in MongoDB and lets users query it in a complicated way[0], but doesn't provide an outright MongoDB-as-a-service implementation, it's still arguably making its functionality available. I don't trust them to enforce the edge cases fairly.
[0] For example, a custom report builder for an inventory management system, or a query builder for a CRM
My take is simple - DBaaS is the leading way databases are going to be confused in the future and SSPL ensures MongoDB is akin Proprietary Databases in this deployment mode - same as with Oracle while other cloud vendors can offer MongoDB they have to do it under the thumb of MongoDB Inc
Open Source is on other hand ensures you have choice of vendors
correct me if i am wrong but imo sspl is a superset of AGPL, because i have read somewhere that agpl fails if kept behind an api. you don't need to publish source and all that.
the problem with non-sspl licenses is, lets say with bsd, that you give the downstream developer the right to decide if your work is part of software which gives source to users when the concern of "Free software" is that end users MUST be given source.
when it comes to cloud providers, even if this agpl license is true, google already bans AGPL software but not aws but i'm not sure but that means they dictate to the end user with vendor lock-in and stuff.
anyways SSPL aims to accomodate even this loophole by making sure if you are a provider, you have to provide source code to ALL software you use. this means, for an end user you can't be forced into a small free software carrot but still subject to rest of closed source.
i'd say this is a win-win for end users, intermediaries and developers don't matter when it comes to freedoms of end users
My issue is more with the software than the license - I'm comfortable running postgres at scale, less so mongodb. This will be great for people like me and widen the range of software that I can use off the shelf.
It doesn't make open source function as free labor for billion dollar companies. Look at the top contributors to OSI and look up that time a Facebook lawyer badmouthed anything but the most liberal licenses at FOSDEM.
Is there a suite of conformance tests and/or benchmarks for MongoDB?
A blackbox test suite that tests common query types and could be run against mongo itself (similar to pgbench, TPC-C, etc) and can optionally test for correctness/speed would go a long way towards making it easier to trust this project with workloads.
The order of fields is maintained by adding a special field with keys in the original order. For example, `{z: 1, a: {y:2, x:3}}` is stored as `{"a":{"x":3,"y":2,"$k":["y","x"]},"z":1,"$k":["z","a"]}`.
FerretDB is very early in its development phase so things can change. Right now it uses JSONB but enhances object with additional meta data, such as field order for example.
I'd be really curious to see if you can use the underlying Postgres to do effective relational queries. This could be an interesting solution for migrating a mongo database to a Postgres database. Or at least having more relational queries for certain things.
1. Postgres's json is limited to standard json. MongoDB supports additional scalar types, like blobs and dates.
2. MongoDB's drivers are designed to handle documents. If you use postgres directly, you have to build that part yourself (effectively a kind of ORM, including a query builder)
I think it’s quite amusing being an ex mongo engineer that the wire protocol and query language is kind of becoming a de facto industry standard with several major products emulating it and now ferret db.
Frankly, I hoped for years for things to be other way around with AWS to take DocumentDB Open Source and keep hosted version on steroids powered by Aurora PostgreSQL.
Having said that I think there is a lot of value in FerretDB for Cloud vendors which will be able to use this project to offer MongoDB Compatible DBaaS experience
Right up until it falls over in a huge mess because Elasticsearch was never designed or intended to be used as a general purpose JSON store. It's a search engine.
Or to quote Kyle from the Jepsen tests, "I would not use this as a system of record".
It doesn't seems to support HTTP protocol. So instead of an 60+MB MongoDB binary, you need Postgres (that's 3 times that size), plus FerretDB, plus a backend. 3 instances to run instead of one, that's a huge trade off.
[+] [-] rapnie|4 years ago|reply
[+] [-] Narretz|4 years ago|reply
[+] [-] philote|4 years ago|reply
[+] [-] hkt|4 years ago|reply
https://github.com/torodb/server
I emailed the project authors a while back and they said that unfortunately it had been abandoned. A shame. I hope the FerretDB people can pull it off.
[+] [-] ahachete|4 years ago|reply
Thank you for mentioning this. Unfortunately, yes, ToroDB is no longer being developed. I still believe it's a fantastic idea, and provides significant value. But when it was being built, 5 years ago, the NoSQL (as in "abandon SQL") state of mind was too strong, and the value proposition was not well understood.
I moved to work on what's always been my passion and preference: Postgres, Postgres, Postgres. For those interested, StackGres[1] is what's now my company's focus.
Things may be different today with ToroDB. The technical foundations and ideas are still there. If there would be significant interest by entities that would like to contribute to its development, it could be considered.
I wish good luck to FerretDB. The task ahead is not easy: MongoDB protocol is very simple, but the API is terribly complex and full of nuances. Getting up and running a simple PoC is very simple. Getting from there to a production quality state with notable compatibility is very hard.
[1]: https://stackgres.io
[+] [-] PeterZaitsev|4 years ago|reply
[+] [-] kellengreen|4 years ago|reply
[+] [-] zokier|4 years ago|reply
> “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 software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available
For example providing SSPL software running on AWS as a service is probably/possibly license infriging because you are not able to provide source code for all the stuff you are using.
In practice probably even the most well-intentioned service provider can easily be trapped by that clause.
[+] [-] strken|4 years ago|reply
If I have a web app that persists data in MongoDB and lets users query it in a complicated way[0], but doesn't provide an outright MongoDB-as-a-service implementation, it's still arguably making its functionality available. I don't trust them to enforce the edge cases fairly.
[0] For example, a custom report builder for an inventory management system, or a query builder for a CRM
[+] [-] pydry|4 years ago|reply
[+] [-] PeterZaitsev|4 years ago|reply
Open Source is on other hand ensures you have choice of vendors
[+] [-] 2Gkashmiri|4 years ago|reply
the problem with non-sspl licenses is, lets say with bsd, that you give the downstream developer the right to decide if your work is part of software which gives source to users when the concern of "Free software" is that end users MUST be given source.
when it comes to cloud providers, even if this agpl license is true, google already bans AGPL software but not aws but i'm not sure but that means they dictate to the end user with vendor lock-in and stuff.
anyways SSPL aims to accomodate even this loophole by making sure if you are a provider, you have to provide source code to ALL software you use. this means, for an end user you can't be forced into a small free software carrot but still subject to rest of closed source.
i'd say this is a win-win for end users, intermediaries and developers don't matter when it comes to freedoms of end users
[+] [-] DeathArrow|4 years ago|reply
[+] [-] hkt|4 years ago|reply
[+] [-] api|4 years ago|reply
[+] [-] hardwaresofton|4 years ago|reply
A blackbox test suite that tests common query types and could be run against mongo itself (similar to pgbench, TPC-C, etc) and can optionally test for correctness/speed would go a long way towards making it easier to trust this project with workloads.
[+] [-] PeterZaitsev|4 years ago|reply
100% Compatibility is not really a focus, real application use cases is. You can read on FerretDB's CEO take on compatibility here
https://www.ferretdb.io/2021/12/07/mongodb-compatibility-wha...
[+] [-] jd_mongodb|4 years ago|reply
https://github.com/mongodb-developer/service-tests
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] CodesInChaos|4 years ago|reply
How does it handle the mismatch between jsonb and bson? In particular:
* more scalar types, including blobs. One hack I could think of is using ISO 8859-1 encoding instead of UTF-8, which can act as a pseudo-blob.
* preserved field order
[+] [-] aleksi|4 years ago|reply
The order of fields is maintained by adding a special field with keys in the original order. For example, `{z: 1, a: {y:2, x:3}}` is stored as `{"a":{"x":3,"y":2,"$k":["y","x"]},"z":1,"$k":["z","a"]}`.
Additional types are stored as objects with special fields too. For example, binary values are stored as `{"$b": "<base 64 string>", "s": <subtype number>}`. The full mapping is there: https://github.com/FerretDB/FerretDB/blob/b7e8240607e043a858...
[+] [-] PeterZaitsev|4 years ago|reply
[+] [-] toshk|4 years ago|reply
[+] [-] cpursley|4 years ago|reply
Postgres jsonb works well enough for me - but this looks like a good alternative for Mongo people.
[+] [-] charcircuit|4 years ago|reply
[+] [-] belter|4 years ago|reply
[+] [-] leros|4 years ago|reply
[+] [-] chespinoza|4 years ago|reply
[+] [-] PeterZaitsev|4 years ago|reply
MongoDB provides "native" document persistence for programming languages, where with PostgreSQL JSON you have to live in relational database SQL land
[+] [-] CodesInChaos|4 years ago|reply
2. MongoDB's drivers are designed to handle documents. If you use postgres directly, you have to build that part yourself (effectively a kind of ORM, including a query builder)
[+] [-] redwood|4 years ago|reply
[+] [-] PeterZaitsev|4 years ago|reply
AWS is not funding FerretDB either
[+] [-] christkv|4 years ago|reply
[+] [-] PeterZaitsev|4 years ago|reply
I think MongoDB did a great job figuring out developer experience for Document Database
[+] [-] tharne|4 years ago|reply
[+] [-] PeterZaitsev|4 years ago|reply
Having said that I think there is a lot of value in FerretDB for Cloud vendors which will be able to use this project to offer MongoDB Compatible DBaaS experience
[+] [-] mdellavo|4 years ago|reply
[+] [-] PeterZaitsev|4 years ago|reply
[+] [-] est|4 years ago|reply
[+] [-] threeseed|4 years ago|reply
Or to quote Kyle from the Jepsen tests, "I would not use this as a system of record".
[+] [-] speedgoose|4 years ago|reply
[+] [-] AtNightWeCode|4 years ago|reply
[+] [-] thisiswarry|4 years ago|reply
[+] [-] Aeolun|4 years ago|reply
I’m not sure what you mean by backend though? You need that regardless right?
[+] [-] soorajsanker|4 years ago|reply
Could you add more details on "Why someone need to choose this over other DBs"from a product PoV or even the DX pov?