[HN Gopher] FerretDB: open-source MongoDB alternative
___________________________________________________________________
FerretDB: open-source MongoDB alternative
Author : yawnxyz
Score : 170 points
Date : 2023-04-12 13:39 UTC (9 hours ago)
(HTM) web link (blog.ferretdb.io)
(TXT) w3m dump (blog.ferretdb.io)
| vorticalbox wrote:
| Does ferret support transactions and document write locking?
| peterfarkas wrote:
| Our development roadmap [1] is based on the needs of the users
| and the software we are focusing on building compatibility
| with.
|
| Interestingly, transactions are not commonly used and therefore
| it is not high on our priority list, it may take months until
| we get to it. Nevertheless, if enough users would request it,
| we would reconsider. The same goes for any other item on the
| roadmap, please check it out.
|
| [1]: https://github.com/orgs/FerretDB/projects/2
| that_guy_iain wrote:
| I'm confused, to me it seems that MongoDB is also open-source.
| Their new license is basically just a better agpl. I only point
| this out because the blog post makes a point of saying it's not
| open source.
| peterfarkas wrote:
| By definition, SSPL is not an open-source license [1].
|
| One could argue that the SSPL brings justice to open-source, as
| cloud providers will not be able to monetize a project without
| giving anything back. SSPL forces them to pay a license fee.
|
| On the other hand, this also creates a vendor lock-in situation
| for the user, simply because not all service providers will be
| able to negotiate a deal with the developer of the SSPL-
| licensed product. This limits choice, limits competition
| between providers, among other things.
|
| This license fee may also be increased at the sole discretion
| of the developer, and the increased fee will be paid by the
| user in the end. This all doesn't sound open-source to me at
| all.
|
| [1]: https://blog.opensource.org/the-sspl-is-not-an-open-
| source-l...
| that_guy_iain wrote:
| Personally, that blog post is just arrogance from OSI. I read
| it. It didn't make clear which freedoms were being removed.
| They are still able to run cloud hosting just release their
| custom code?
|
| And OSI thinking they alone get to decide what is and what is
| not open source is arrogant.
| peterfarkas wrote:
| While I do respect your opinion, I disagree.
|
| I think that arrogance is when a single vendor tries to
| single-handedly redefine open-source to fit their business
| needs better. Not just a license, but the definition
| itself.
|
| A quote from the MongoDB CEO: "MongoDB was built by
| MongoDB. There was no prior art. We didn't open source it
| for help; we open sourced it as a freemium strategy". [1]
|
| Whether the OSI was arrogant or not, I really don't want
| this person to define opensource.
|
| [1]: https://techmonitor.ai/leadership/strategy/mongodb-
| ceo-inter...
| that_guy_iain wrote:
| I am not really sure what your issue is. What you think
| open-source as freemium isn't a model?
|
| If it wasn't for copy-left licenses that forced companies
| to release code that they used to create their products
| we wouldn't have Linux in its current state.
|
| In a world, where many products are cloud based it seems
| fair and within the current model of open source to force
| code sharing.
| aleksi wrote:
| > They are still able to run cloud hosting just release
| their custom code?
|
| The SSPL license reads:
|
| > [...] you must make the Service Source Code available via
| network download to everyone at no charge, under the terms
| of this License.
|
| > "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.
|
| You just can't comply with those terms if you don't have
| access to the source code of your storage software, for
| example.
|
| (but I'm not a lawyer, of course)
|
| > And OSI thinking they alone get to decide what is and
| what is not open source is arrogant.
|
| OSI invented the term "open source": https://web.archive.or
| g/web/20021001164015/http://www.openso... I think they are
| in a position to define what it means.
| that_guy_iain wrote:
| I am confused. If you use a custom storage system then
| you would have the code for it. No?
| mitjam wrote:
| Yes and custom network software for routers, switches,
| firewalls, and custom OSes etc.
| that_guy_iain wrote:
| Those aren't listed are they? The idea you need to
| release code for the os, file system, network routers,
| etc is absurd.
| vrtx0 wrote:
| No, full list is in the license, but it's only those
| components that they provide MongoDB as a service to end
| users. Doesn't penetrate OS abstractions AFAICT, but I'd
| check the license and/or consult an expert if starting a
| relevant business!
|
| FWIW, just realized it doesn't even apply if deployed
| internally (within an organization and/or
| subsidiaries)...
| zokier wrote:
| 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 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.
|
| Basically it is saying you need to release the source of
| every tiny bit in your stack and then some.
| vrtx0 wrote:
| No, the term "open source" was in use before long before
| the OSI, and it was in popular/hacker culture in the
| 1980s. UNIVAC used it in for a major system in the 1950s.
| [1] I used it in 1993 (I wrote a small BBS).
|
| The OSI looks and sounds like an authority on open source
| software, but their entire strategy is legal, political
| and quasi-philosophical. I get how easy it is to be
| mislead by them though -- they're good at spinning things
| and rewriting history.
|
| https://en.m.wikipedia.org/wiki/History_of_free_and_open-
| sou...
| PeterZaitsev wrote:
| There are 3 "competing" Open Source and Free Software
| definitions - from OSI, Free Software Foundation and
| Debian. MongoDB does not match any of them and most
| importantly does not match the spirit of Open Source
| Software Movement.
| that_guy_iain wrote:
| Please state in what way they don't? This is what I'm
| confused about. Apgl is open source but a sspl isn't?
| They seem to be aimed at solving the same thing, which is
| cloud/server based code modifications.
| peterfarkas wrote:
| SSPL goes way beyond AGPL as it contains an additional
| clause called "Offering the Program as a Service". It is
| not defined at all what constitutes providing MongoDB as
| a service. How many layers are needed to abstract MongoDB
| in a way that it doesn't trigger this clause? There are
| no answers for that in the SSPL. It comes with an
| enormous amount of risk compared to AGPL. There is a good
| article from Dor Laor at ScyllaDB which explains this in
| detail [1].
|
| Moreover, cloud providers are not limited to AWS, Azure
| and GCP. Smaller providers whom we talked to are not able
| to negotiate licensing terms with MongoDB the same way as
| how AWS could. For this reason, these providers are not
| able to provide MongoDB as a service. Yes, it's great for
| MongoDB that they were stopped from providing MongoDB for
| free, but now they can't provide the service at all. This
| limits competition and choices, and that is never in the
| favor of users.
|
| [1]: https://www.scylladb.com/2018/10/22/the-dark-side-
| of-mongodb...
| that_guy_iain wrote:
| AGPL is basically the same thing, except far more
| reaching. AGPL, to my understanding, makes it a
| requirement if you allow people to use the software via
| network levels. "Program as a Service" seems a lot more
| limited in scope.
|
| All new licenses come with risk since the decisions can
| only be made via court decisions.
| vrtx0 wrote:
| I could name more, but let me clarify something. I'm not
| a fan of the SSPL, but I get why it was necessary.
|
| It was rough seeing huge cloud providers profit off open
| source projects without giving anything back. When they
| offered competing hosting services with no value added
| (well, past "integrated billing"), no contributions or
| innovation, _and_ drove their new customers to the
| documentation and libraries of the companies backing
| these projects, they crossed a _huge_ line.
|
| And it's not just MongoDB. Or Elastic. Just look at all
| the "services" AWS offers, and note how many AWS actually
| invented or even contributed to...
|
| Monopolistic practices forced a lot of companies to
| either shut down, or find a way to survive. I'm glad
| MongoDB decided to use the SSPL instead of shut down like
| so many others. I'm glad they've continued to thrive.
|
| Changing to the SSPL isn't ideal, but it only impacts
| people who want to sell hosted versions of the software
| (not users, self-hosted or otherwise). For those
| _infinitesimal_ few selling hosted versions of the
| software, it doesn't even stop them from doing what they
| want -- it just stopped the monopolies from destroying
| something a lot of people dedicated a lot of effort to...
| That seems like a pretty amazing feat to me, given the
| reality...
|
| I wish the OSI wasn't so successful painting users of the
| SSPL as somehow betraying the open source community. And
| I wish the SSPL wasn't necessary. But until there a
| better option, I'm ok with the SSPL...
|
| Again, I say this with all due respect, and this is just
| my opinion. Corrections and new perspectives welcome!
| vrtx0 wrote:
| MongoDB's source code is still freely available. It's still
| actively developed in the open on GitHub. Unless you're
| offering MongoDB as a service, it's just as "open source" as
| ever.
|
| If you want to offer MongoDB as a service, you can still do
| so free of charge, as long as the service infrastructure is
| also made openly available, right? And if you don't want to
| make the source available, you can purchase a license and do
| so, right?
|
| Furthermore, if you're using MongoDB, be it self-hosted, with
| a vendor, or even some proprietary database that implements
| the wire protocol for compatibility, you're likely using
| MongoDB-developed clients/drivers, which are Apache 2.0
| ("OSI-approved open source").
|
| So it seems like the only way to be locked into a vendor is
| if you're using MongoDB drivers to connect with a 3rd party
| database that doesn't fully implement all functionality of
| MongoDB in a compatible way... Right?
|
| I could be wrong, but as someone who contributed to MongoDB
| as an open source project, and was later hired by MongoDB
| based on said contributions, it kinda hurts to see the OSI's
| "MongoDB isn't open source anymore" campaign work so well.
|
| That said, I sincerely wish the team behind this project all
| the best!
|
| My complaints aren't against anyone in the open source
| communities I've known and loved. Just this self-important
| legal organization that acts like it controls (and even gets
| to define) open source software.
|
| P.S. I left MongoDB in 2015 due to a neurological disability,
| but it was one of the highlights of my career, with so many
| kind and brilliant people. But it's also been a while, and my
| brain doesn't work so well these days, so please correct me
| if I got anything wrong!
| PeterZaitsev wrote:
| "You can do so as soon as you open source infrastructure"
| is impractical and misleading. It is very likely part of
| infrastructure will be commercially licensed so even if one
| would want to open source it, it would not be possible.
|
| MongoDB Specifically switches from Open Source License to
| SSPL to create monopoly in DBaaS Space. IT is business
| decision so lets not pretend here.
|
| If you look at Real Open Source software it is created for
| cooperation and innovation together, not monopoly.
| vrtx0 wrote:
| 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 suggestion of a monopoly in the DBaaS space seems to
| preclude the existence of other databases... Or am I
| misunderstanding?
|
| I'm not sure what you mean by "IT is a business decision"
| -- could you elaborate?
|
| -edit- P.S. I'm trying to be supportive here; not trying
| to take anything away from what you've built with
| FerretDB! Honestly, there's room for so room for
| innovation in this domain, and it's nice to see new
| projects...
| zokier wrote:
| > 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?
| zokier wrote:
| > If you want to offer MongoDB as a service, you can still
| do so free of charge, as long as the service infrastructure
| is also made openly available, right?
|
| The license text is worded as such that it is basically
| impossible to comply with.
|
| > OSI's "MongoDB isn't open source anymore" campaign work
| so well.
|
| It is hardly OSIs campaign. Pretty much all major
| organizations involved in FOSS licensing have rejected
| sspl. For example this is Fedoras stance:
|
| > Fedora considers the Server Side Public License (v1) to
| be a Non-Free license. It is the belief of Fedora that the
| SSPL is intentionally crafted to be aggressively
| discriminatory towards a specific class of users.
| Additionally, it seems clear that the intent of the license
| author is to cause Fear, Uncertainty, and Doubt towards
| commercial users of software under that license. To
| consider the SSPL to be "Free" or "Open Source" causes that
| shadow to be cast across all other licenses in the FOSS
| ecosystem, even though none of them carry that risk.
| ahachete wrote:
| > "Unless you're offering MongoDB as a service, it's just
| as "open source" as ever."
|
| It's not. It's source available, and that's still
| proprietary.
|
| The reason why the SSPL is not Open Source is pretty
| simple: it doesn't convey the four essential freedoms of
| free software [1]. That's it, there is essentially no more
| to it: it imposes usage restrictions, and that's
| orthogonality against the spirit.
|
| Whether it is "except this or that" or "AGPLv3 but with
| this additional clause" is irrelevant: even the tiniest
| change can cause significant differences, and this is the
| case: it removes the freedom to run the program as you
| want, as it imposes restrictions to some use cases. And
| these restrictions go beyond the realm of the software
| itself.
|
| In contrast, Open Source copyleft software, like AGPLv3,
| never go beyond the software itself. It provides guarantees
| that modified versions of it also remain available for
| users of modified software (forward carrying guarantees)
| but do not add a requirement to also provide under the same
| license other unrelated software (which is essentially a
| nice way of saying "simply don't do this", turning de facto
| into a usage restriction).
|
| [1]: https://www.gnu.org/philosophy/free-sw.en.html#four-
| freedoms
| dang wrote:
| Related:
|
| _FerretDB 1.0 GA: open-source MongoDB alternative built on
| Postgres_ - https://news.ycombinator.com/item?id=35524235 - April
| 2023 (2 comments)
|
| _FerretDB: A truly open-source MongoDB alternative_ -
| https://news.ycombinator.com/item?id=29448906 - Dec 2021 (110
| comments)
|
| _MangoDB has a new name_ -
| https://news.ycombinator.com/item?id=29407987 - Dec 2021 (5
| comments)
|
| _Open source MongoDB drop-in replacement, built on top of
| Postgres_ - https://news.ycombinator.com/item?id=29096331 - Nov
| 2021 (2 comments)
|
| _MangoDB: An open-source MongoDB alternative_ -
| https://news.ycombinator.com/item?id=29071623 - Nov 2021 (200
| comments)
|
| _Show HN: MangoDB_ -
| https://news.ycombinator.com/item?id=4139723 - June 2012 (2
| comments)
| [deleted]
| kbd wrote:
| 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, MongoDB has grown out of the reliability issues it had in
| the past, and Postgres has json features for the occasional times
| it's useful to store some loosely structured data along with
| otherwise relational data. Question is, what applications is a
| document-first database good for, outside of prototyping?
|
| Edit: and to make sure I understand, FerretDB is a layer
| reimplementing MongoDB on top of Postgres and its json features?
| tracker1 wrote:
| Looks that way to me... I really liked a _LOT_ about MongoDB, I
| don 't think they had a good story for administration of scale
| + redundancy. RethinkDB, Cassandra and others have a ring +
| redundancy model which I think is easier to deal with. Where
| Mongo at least was limited to replication or sharding, and was
| a serious pain to deal with from the admin side imo.
|
| Understanding the advantages and shortfalls is sometimes harder
| too. Mongo having multiple secondary indexes is pretty nice as
| well. Haven't dug into FerretDB, my first question is if it
| will run over the top of CockroachDB, as that's how I would
| probably want it configured. Then, I'm not sure if I wouldn't
| just use the JSONB surface in PostgreSQL/CockroachDB directly.
|
| I think it just really depends on how/what you need to
| accomplish.
| peterfarkas wrote:
| 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-commerce, for example),
| and we should not discount the fact that using a relational
| database is just more complicated. Using vanilla Postgres for a
| MongoDB use case will not be feasible for someone who's focus
| is, let's say, mobile application development. There is a
| reason behind MongoDB's popularity - it just provides a great
| developer experience. This is what we are aiming to recreate on
| top of Postgres.
|
| [1]: https://blog.ferretdb.io/pjson-how-to-store-bson-in-jsonb/
| Zababa wrote:
| I'm curious about what makes document databases a good fit
| for e-commerce. I've never worked in that industry.
| mitjam wrote:
| A use case I have for FerretDB is migrating existing apps off
| MongoDB without needing to change the code. I find it funny
| that you could call these now ,,legacy" apps.
| peterfarkas wrote:
| Exactly. Let's say a major company have a few applications
| which require MongoDB, and the rest of their applications are
| running on Postgres.
|
| With FerretDB, they can migrate the app off MongoDB as you
| said, and keep Postgres only. Therefore they don't need to
| maintain internal knowledge on how to run MongoDB, or pay for
| MongoDB to run it for them (in which case they are not in
| control of their data, because it is all under MongoDB's
| account...).
|
| This is one real world user example.
| kiney wrote:
| Insert <look at me, I am the legacy app now> meme here
| aranchelk wrote:
| > Question is, what applications is a document-first database
| good for, outside of prototyping?
|
| Some criteria I'd use: * Data is already naturally segregated
| and won't be shared/joined much during normal usage * App
| already has transactions modeled in the application layer (or I
| guess if consistency really doesn't matter) * App would benefit
| from being geographically distributed. * App is written in a
| language with a strong type system, has high code quality, test
| coverage, etc.
|
| In my case, my company makes a distributed project management
| application. All changes to projects are canonically ordered
| and applied in the application layer.
|
| Data is stored in Cloudflare Durable Objects and R2. Hard to
| classify DOs but they're a lot closer to a document store than
| an SQL Db.
|
| There are some nice benefits that would be hard to replicate
| with a traditional SQL Db setup.
| tristan957 wrote:
| One thing that I didn't see discussed was why FerretDB uses
| Postgres as a backend and not a storage engine. Perhaps I am just
| missing something though.
| PeterZaitsev wrote:
| Because PostgreSQL Is fantastic Open Source database engine,
| very popular with a lot of operational experience and tooling
| support.
|
| This is Open Source way of doing things - having project focus
| on as narrow problem as possible (first) and leverage as much
| of existing componets as possible.
| rmangi wrote:
| Cramming an api for one product on top of another is
| absolutely not "the open source way" I'd expect a much better
| explanation for this Frankenstein's monster. This seems like
| it would work but never scale.
| tristan957 wrote:
| Ok, that makes sense. I guess this project is targeting a
| compatible frontend for multiple backends. When I saw MongoDB
| alternative, I thought they were building both sides of the
| coin.
| manishsharan wrote:
| This looks great. I had been using Document Layer for
| FoundationDB but Apple has abandoned the Document Layer for the
| FoundationDB ; so this looks promising .
| richieartoul wrote:
| Tigris(https://github.com/tigrisdata/tigris) is one of the
| supported FerretDB backends and Tigris is backed by
| FoundationDB, so you can still have the Mongo interface with
| the reliability and scaling of FDB if that's what you're
| looking for
| ahachete wrote:
| I applaud this effort.
|
| Many years ago I founded a project called ToroDB [1]. ToroDB had
| a vision very similar to that of FerretDB's: help MongoDB users
| feel at home on Postgres. This has far reaching implications,
| like allowing MongoDB applications to run without MongoDB (this
| is what FerretDB is essentially and what "ToroDB Server" was
| meant to be) or to replicate data from MongoDB to Postgres to
| improve the performance of analytical queries by several orders
| of magnitude (that was "ToroDB Stampede").
|
| ToroDB ended up being discontinued. Timing was not right. At the
| time, NoSQL was exploding, and users "didn't want to look back to
| SQL" --until they learned the notable advantages, but it was a
| time consuming and hard job. Today, there's a much higher
| acceptance of SQL and most recognize that data querying in many
| cases goes through, or is significantly helped, by SQL.
|
| I wish FerretDB a successful road and reach to where ToroDB
| didn't reach at the time. Good luck and congratulations on the
| 1.0 launch!
|
| [1]: https://torodb.com
| nacs wrote:
| Looks like they mentioned your DB in a (probably SEO-bait) blog
| post here:
|
| https://blog.ferretdb.io/5-database-alternatives-mongodb-202...
| quasilyte wrote:
| Congrats with v1.0! I remember the times when it was called
| MangoDB. :D
| aleksi wrote:
| Yeah, those were easier times for sure :)
| deepsun wrote:
| 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
| prefer).
|
| Turned out that was much faster to run analytical queries :)
|
| "document" is just row
|
| "collection" is just table
| softfalcon wrote:
| I would recommend against modeling too many relations in a
| document DB. It can work, but it gets bogged down very quickly
| for the reasons you've stated.
|
| My off-the-cuff suggestion is that document databases are not
| built to model normalized relational data. If you try to do so,
| you bring a whole new level of pain upon yourself. It is do-
| able, but it is hard and annoying.
|
| I know this from extensive personal experience dealing with a
| large, highly relational Mongo database.
|
| I am very glad you found a solution within Postgres that works
| for you, and your mapping of document to row and collection to
| table is very apt!
|
| If possible, would you care to tell me what the size of said
| documents (rows) and collections (tables) are in your solution?
| I am curious if in another life, we might have built our tech
| stack on Postgres instead of MongoDB and been much happier for
| doing so.
| tasubotadas wrote:
| 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.
| tracker1 wrote:
| Yeah, I've kind of railed against ORMs for a while now...
| I'd just assume a simple data mapper (like Dapper for C#)
| or be really explicit in a scripted language with template
| queries.
| skatanski wrote:
| 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.
| mgfist wrote:
| 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.
| eropple wrote:
| If you aren't normalizing, how are you ensuring that you
| don't avoid anomalies?
| saghm wrote:
| Not sure if this is exactly what you're referring to, but
| my understanding is that picking the "right" schema for a
| document database to ensure that you don't end up with
| slower queries like mentioned elsewhere in the thread
| tends to benefit from thinking at a somewhat lower level
| of granularity than you would probably need to with a
| relational database. Instead of just identifying "one to
| one", "one to many", "many to many", it's useful to ask
| questions like "how 'many' is many"; as a simple example,
| if the "many" in "one to many" is on the order of 10,
| maybe it makes sense to embed them in an array rather
| than use a separate collection for them. It can also help
| to start from thinking about the types of queries you
| might want and then designing the schema based on them
| rather than starting by deciding on the schema and then
| having the queries be based on that; if you're going to
| want certain data to be accessed at the same time, you're
| probably going to find some way to store it together.
| skatanski wrote:
| 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.
| forgetfulness wrote:
| 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 that's an
| optimization and it'd be competing with Redis for what
| matters there.
| packetlost wrote:
| 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.
| aleksi wrote:
| 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.
| udp wrote:
| The json standard has nulls
| phendrenad2 wrote:
| MongoDB really only makes sense when you have an extremely
| large set of documents and you don't need to do this kind of
| statistics.
| audioheavy wrote:
| This sounds like an interesting hybrid implementation, and I
| understand its motivation. However, if distributed writes at low
| latency with the highest consistency guarantees are essential,
| combining those two layers (Mongo and PostgreSQL) isn't worth the
| complexity. It looks like you can administer it with both Mongo
| and PostgreSQL tools, but do you want to? Clusters, partitioning,
| replication? That's a lot of heavy lifting.
|
| To fully disclose, I have a biased view on this given that I work
| for a (closed source) serverless, no-ops DB provider (Fauna) that
| implements a distributed transaction engine that is natively
| document-relational and doesn't compromise on relational (ACID,
| transactional) guarantees. Although not directly comparable to an
| OSS DB, The market expects software and services to abstract as
| much complexity as possible. It is hard to imagine how such a
| Mongo/Postgres hybrid could handle hyper-scale apps that require
| highly consistent distributed writes.
| jchannon wrote:
| If it can run a replica set on an apple m1 which mongo can't
| currently do then great!
| vrtx0 wrote:
| 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!
| singeezie wrote:
| if ferretDB truly does provides ad-hoc queries, indexing,
| aggregation, and real-time data processing, making it well-suited
| for a wide range of applications, then sure , it's a great
| alternative . I can see all types of web apps even enterprise
| systems working well w it.
| peterfarkas wrote:
| FerretDB maintainer here.
|
| We already offer basic support for aggregation and indexing,
| and we are adding as many features as we can, see our roadmap
| [1].
|
| We are mainly building on our user's experience with running
| FerretDB and add features to our roadmap accordingly. We are
| not aiming to implement the entire feature set of MongoDB, of
| course, but the majority of MongoDB workloads are not utilizing
| the full feature set, either.
|
| [1]: https://github.com/orgs/FerretDB/projects/2/views/1
| jzelinskie wrote:
| Congrats on the launch! Your GitHub Project board looks nice
| and clean. Do you have any posts or code for how your bot is
| managing issues there?
| aleksi wrote:
| That's easy, really. There was a person behind ferretdb-bot
| account - me. :) I still maintain our projects mostly
| manually.
|
| That being said, we do have some automation in place. The
| public part is there: https://github.com/FerretDB/github-
| actions We are planning to do more there, open source the
| other part, and then blog about it.
| brightball wrote:
| I'm still waiting for the NoSQL crowd to realize that the best
| use case was always handled by CouchDB.
| josevalerio wrote:
| Another day on the orange site where people don't understand that
| you can 100% have relationships in a NoSQL database - just don't
| try to do it the same way you do in a "relational" one or you're
| going to have a bad time. Storing everything in one collection is
| critical.
|
| Here is an example using multi key indexes with Rick Houlihan
| from re:Invent 2022: https://youtu.be/eEENrNKxCdw?t=1131
___________________________________________________________________
(page generated 2023-04-12 23:00 UTC)