Show HN: MongoDB Protocol for SQLite
github.com
github.com
This is not true, you can use MongoDB for commercial projects as long as you don't sell MongoDB services, but internally you're free to use it as your regular DB.
https://www.mongodb.com/licensing/server-side-public-license...
For example, many consider GPL to be a great OSS license, but it’s restrictive enough that some BSD projects try to avoid it.
BSD vs GPL vs LGPL are pretty dramatically different, and there are many in-between that might satisfy the definition of “open-source” at face value.
OSS is IMO a very subjective term. There is a massive gray area surrounding open-sourcing derivative works, etc. and other stipulations.
[1]: www.ssplisbad.com
The author, of course, relies on the claimed vagueness of the license as an excuse to take every claim to the most ridiculous extent possible, even though no reasonable person would believe anything claimed here, such as the suggestion that it might entail you release the source code for your computer's BIOS.
In a section with truly atrocious spelling and grammar, the author asserts that somehow this kills real competitors (even though real competitors would presumably have their own actual product offering, not just re-ship a product offered by the SSPL software developer at a predatory pricing rate only made possible through monopolist behavior). They then make the ridiculous claim that this entirely removes the ability for the customer to choose their cloud provider. Meanwhile, in the land of reality, between either forks or licensing agreements, there is plenty of competition, but the developers have an opportunity to sustain development instead of all of the profit being skimmed off by Amazon, who contributes nothing back and does none of the work. Having to raise their prices above the original developers' due to license fees, of course, doesn't even remove the value add for choosing AWS, where the benefits are bringing it into the same datacenter and platform as the rest of your other cloud needs.
The author then tries to villainize software companies using SSPL by pointing out how many thousands of employees and how many millions in revenue they have, without acknowledging that the sole benefactor of making SSPL look bad is Amazon, which brings in hundreds of billions of dollars of revenue and has over 1.5 million employees.
This train wreck is then finished up with their suggestions that these companies should just remain unsustainable and rely entirely on business models for open source we all know don't work very well.
I would say the author is arguably wasting their $10 a year domain registration on this garbage article, but considering the lack of public attribution present, I assume Amazon's paying for it.
> considering the lack of public attribution present, I assume Amazon's paying for it.
Well, that was a wild ride.
Though I am absolutely fine with you dismissing my parting shot on those grounds indeed.
Apparently the firm put the company through the wringer (and more than likely bumped down their valuation during the transaction) over MongoDB’s licensing.
I have a feeling in this specific case, [top ten firm] probably found some technicality in MongoDB’s licensing that allowed them to use as negotiating leverage to bump the price down during the transaction.
Licensing is important. You especially don’t want ambiguous licenses that give lawyers wiggle room to make absurd nonsensical arguments, which unfortunately is very common even with reputable investors and firms.
Edit: Removed name of firm for legal reasons. Email me if you want specifics. bp@brandonpaton.com
That's a lot of legal risk for your commercial project.
1: https://lists.opensource.org/pipermail/license-review_lists....
2: https://lists.opensource.org/pipermail/license-review_lists....
3: https://www.processmechanics.com/2018/10/18/the-server-side-...
But yes, it’s still a mess of a license that creates a lot of legal uncertainty for potential licensees, especially if a particular court decides that the copyright misuse defense doesn’t apply but that unclean hands does apply to the licensee for taking a license without intent to comply (e.g. because of having already concluded that compliance was impracticable or impossible).
Definitely best to avoid the SSPL and software licensed under it.
I guess having yourself exploited and ultimately destroyed by monopolist overlords is the moral choice or something? Or do boots just taste good?
https://logz.io/blog/open-source-elasticsearch-doubling-down...
Great project of yours! Thank you
* will try to hack docker-compose for this if time allows
Mongo's sharding is nice but I'm really tired of their support. They force you to run smaller machines in the contract so they can charge more for # of nodes, and it adds complexity to your architecture so you're swayed into buying Atlas. I could replace it all with a few PG shards with bigger machines.
It's such a perfect tool for my side projects and most projects that will never reach Twitter scale
If I have more than 10k users, I'd have more problems
???
When I used Heroku, Postgres was a checkbox. Can't get any easier than that.
I understand that it's more work to set up a schema, as opposed to just dumping data structures into a data store. But, as I described elsewhere in this thread, the flexibility to query any table will help dramatically as your requirements change throughout the lifetime of a product.
Shame too because the sync between couch & pouch was super cool. Feels like the way things should work.
In the case of this code, CouchDB was simply being used as a dumb key-value lookup. We weren't using any special features of CouchDB.
Of course, a lot has changed since, so the problems I encountered might not exist.
Basically, CouchDB needed to periodically run a gargage-collection-like operation. (If I remember correctly, records were not deleted, but instead hidden until you run the cleanup.) The problem was that the cleanup process was so unoptimized that CouchDB copied the entire database without the deleted records. In our case, the disk we had was about 90% occupied, so we couldn't run cleanup.
So why was CouchDB a failed experiment:
First: The problem with handling deletions was rather serious, for a database. It's quite painful for a database to need 2x your anticipated storage; and for that database to continue creating records even if it blocks something like garbage collection. This lead me to conclude that the database could have other bugs lurking. I need to trust that the database won't lose data or become inoperable due to its own bugs; or due to beginner mistakes with unfamiliar technologies.
Second: CouchDB offered no features that I needed for my project that I couldn't get elsewhere. I just needed simple key-value lookups.
Third: Learning curve: Everyone and their dog knows SQL. This was handling a niche use case, so most likely, whoever was touching it was going to be very unfamilar with the code. Picking a well-known SQL database helps keep that learning curve in check.
I actually don't know SQL very well (coming from design), so something like Couch feel more intuitive to set up as it looks and feels like JS / JSON, with neat additions like views.
I think I'll keep using Couchdb for my tiny projects, with the caveat that "if something gets bigger and more well-defined, start learning SQL" (or at least properly learn Supabase)
That's a huge, huge gap in your skillset. SQL databases are generally the one-size, fits-all of databases. There's good reasons (very good reasons) to use alternate databases; but they tend to be outside of the primary use cases of an application.
One of the very important features of SQL is that how you query your data isn't tied to the structures that are convenient for a particular use case.
Basically, the problem with using CouchDB and MongoDB as a general purpose database is that you're storing and querying data structures, or documents. It's easy early in a project, when your use cases are small.
The problem comes later in the project, when a requirement comes to query a data structure that's deeply nested inside of a document. This can incur a rather substantial performance penalty, unless you denormalize your data.
For example, when I used to go to MongoDB conferences, they used the example of a message board, where all messages in a post were stored in the same document. (For example, imagine that all messages in this thread are stored in a single document.) The problem then comes when you need to support a page like https://news.ycombinator.com/threads?id=gwbas1c, that lists all posts that I've made.
In the case of SQL, supporting a page like https://news.ycombinator.com/threads?id=gwbas1c is merely writing a new query and updating an index. It doesn't require denormalization or scanning many documents.
> I actually don't know SQL very well
Another reason why it's important to understand SQL basics comes from being able to write code that performs well, within reason. I constantly inherit code that uses an ORM (library that translates between SQL and objects), and the code just can't perform.
The original authors didn't know SQL at all, and just assumed that the ORM would do the heavy lifting for them.
> I actually don't know SQL very well
You don't really need to know much SQL to get by: Just four commands, "select, insert, update, delete," (and upserts) and then understand joins. Understand transactions, and you're all set. You can leave the more advanced features to when you need an advanced database feature.
Even stories of it being successful with the Postgres backend would be really helpful.
Running Unifi on NixOS is a bit of a pain since the license means that there is no binary cache for the package, resulting in frequent rebuilds.
I’ve also not had a great time with the mongo upgrades in the past that caused my controller to not start.
Yes, querying it with SQL should be possible.
https://github.com/FerretDB/FerretDB/issues/5
I presume, that after there is feature parity, then someone could run some benchmarks.
I find it intriguing to note a comparable approach by MySQL, where it functions as a NoSQL database, specifically a document database, owing to its adoption of a multi-paradigm methodology.
Starting from version v5.7.12, MySQL provides the "MySQL Document Store" feature, which enables data access through a document interface utilizing the proprietary XProtocol protocol. It is important to mention that this protocol is incompatible with MongoDB. The fascinating aspect is that the data can be modified interchangeably using both XProtocol and SQL.
Something something HN and pitchforks.
Your applications would be talking to it over a socket using a known and documented protocol so the implementation language isn't something the client code should be expected to need to care about at all.
Given those two facts, I genuinely don't understand what your concerns are here?