[HN Gopher] Show HN: MongoDB Protocol for SQLite
___________________________________________________________________
Show HN: MongoDB Protocol for SQLite
Author : aleksi
Score : 59 points
Date : 2023-07-04 18:35 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| winrid wrote:
| If this implemented sharding it'd be killer. I recognize that'd
| be a huge amount of work, but that would be amazing! I may do
| that someday. You could just use one PG instance as the config
| servers and this takes place as the mongos.
| peterfarkas wrote:
| Maintainer here. That's a very good idea! Let us know if you
| ever have some time to work with us on this.
| throwaway888abc wrote:
| You should speak to PayloadCMS guys. It can be mutually
| benefiting (publicity/more users/etc.). It needs Mongo, but
| if it works with Ferret backed by SQLite (and others) that
| would be game changer.
|
| https://payloadcms.com/
|
| Great project of yours! Thank you
|
| * will try to hack docker-compose for this if time allows
| peterfarkas wrote:
| Thank you, we will take a look!
| winrid wrote:
| Awesome! This might be my new Sunday project once I'm done
| with the current one.
|
| 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.
| peterfarkas wrote:
| Yes this is one of the reasons we started FerretDB. Atlas
| is very easy to use, but it is nearly impossible to move
| away from later on, as there is no alternative (unless you
| are ready to rewrite your app). We think that most of its
| killer features, like easy sharding, can be done with
| Postgres and/or SQLite.
| winrid wrote:
| I agree. I'd love to work on this full time if I could.
| Scarbutt wrote:
| _MongoDB was originally an eye-opening technology for many of us
| developers, empowering us to build applications faster than using
| relational databases._
|
| Something something HN and pitchforks.
| Eumenes wrote:
| But is it still web scale?
| aleksi wrote:
| Not yet, but let us turn off fsync...
| Mertax wrote:
| Is there any documentation on the native schema used to store the
| documents. Is it sane enough that you could manually roll your
| own JSON1 queries in SQL to facilitate more relational join like
| features?
| aleksi wrote:
| Some time ago, we wrote a blog post about it:
| https://blog.ferretdb.io/pjson-how-to-store-bson-in-jsonb/ A
| few details changed after that (for example, type information
| is not mixed with values anymore), but the general idea is the
| same. We probably need to document it better.
|
| Yes, querying it with SQL should be possible.
| jhatemyjob wrote:
| Man this is _exactly_ what I need at a high level but not writing
| this in C is a complete show-stopper. All that Docker effluvium
| adds insult to injury. Sad!
| winrid wrote:
| It's mostly meant as a service. This is a great application for
| Go.
| aleksi wrote:
| FerretDB is written in Go, can be used as a Go library, and you
| could call it from C via CGo... But I would not do that :)
| jhatemyjob wrote:
| Haha. The thought process behind using Go was probably like:
| "Great! SQLite is written in C. That means I can write my
| library in Go! And use microservices!"
| aleksi wrote:
| FWIW, we use a version of SQLite transpiled into Go to
| avoid CGo problems: https://gitlab.com/cznic/sqlite
| Thaxll wrote:
| "However, as time passed, MongoDB abandoned its open-source
| roots; changing the license to SSPL - making it unusable for many
| open source and early-stage commercial projects."
|
| 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...
| peterfarkas wrote:
| It's a little more complicated than than just having to refrain
| from selling MongoDB services. There is a good page which
| summarizes the problem with SSPL. [1] SSPL is crafted in a way
| that it very hard to tell whether you comply with the license
| or not, especially if you run it as part of a cloud hosted
| solution.
|
| [1]: www.ssplisbad.com
| cj wrote:
| I was talking to the VP of Engineering at a company that got
| acquired by [top 10 VC/PE firm].
|
| 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
| jcstryker wrote:
| That condition is not in the spirit or commonly accepted
| definition of open source.
| pnpnp wrote:
| "Open source" tends to be a spectrum.
|
| For example, many consider GPL to be a great OSS license, but
| it's restrictive enough that some BSD projects try to avoid
| it.
| peterfarkas wrote:
| It tends to be a spectrum, but the various, sometimes very
| different licenses adopted by the OSI still have something
| in common - the open source values laid out in the Open
| Source Definition. [1] SSPL did not comply with this
| requirement, as it discriminate against specific users or
| use cases. I think it is in the interest of everyone to
| draw the line somewhere.
|
| [1]: https://opensource.org/osd/
___________________________________________________________________
(page generated 2023-07-04 23:00 UTC)