Live data from Hacker News

Show HN: Mongita is to MongoDB as SQLite is to SQL

github.com

41–50 of 95 posts

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#41
post #36

Earlier quoted context omitted.

Author here. My goal with that one-liner was to convey immediately what it is - an embedded database that implements the PyMongo/MongoDB API. Is it semantically perfect? Probably not. Will Mongita be useful to Python developers who are accustomed to saving their data in idiosyncratic JSON files because they don't want the overhead of a MongoDB server? Maybe! I hope so.

Thanks for sharing your project. It’s probably not a good comparison. SQLite is in such high esteem and such a well developed high quality mature product. So the comparison is sort of inviting criticism that gets in the way of people appreciating what is good about your project.

This is good and helpful feedback. Thank you. I'm humbled by how well this has done so far but definitely feeling the criticism. A title like, "Mongita is embedded MongoDB for Python", while being a statement without ambiguity, doesn't immediately convey the vision for why this might be useful to people. SQLite by contrast is a nice rhetorical anchor that people understand. I'll have to think through whether there is a better way to convey it that fits that goal.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#42
post #39

Earlier quoted context omitted.

The project isn't about performance, it's about providing an embedded version of MongoDB - it clearly states that if you grow too large, then you can easily migrate to the full MongoDB. It also clearly states not to use it if you want a relational database.

I am not even sure what is going on now, as I thought the only reason people had ever cared about MongoDB in the first place was in an attempt to get performance they thought was impossible using a relational database (notably without realizing all of the tradeoffs... some inexcusable, such as simply coming with defaults that didn't call fsync, leading to a ton of memes about "database administrators running with sci…

Having the best performance isn't necessary for a lot of use cases. Sometimes you just want to store and search a bunch of json objects and for that the mongo api is way more convenient then the postgres/sqlite json options

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#43

Cool project but I have to admit I sure wish this was written on top of SQLite, rather than just mentioned it, implementing a query language shim for MongoDB on SQLite would be an amazing project. In the absence of such a project though, this is a pretty great alternative to have.

Thank you! I actually did consider doing exactly what you said. Early on, I decided one my goals for the project would be to make it easy to swap back and forth between Mongita and PyMongo/MongoDB. For me, that meant getting as close as possible to their implementation and using things like BSON, ObjectIds, etc. For that, I sacrificed some performance but I think most people who would use something like Mongita would…

Oh thanks for the insight, that makes a lot of sense -- pretty sure mongita is one of the first projects I've seen even attempt this, and it makes sense to target the platform that fits your use case (and obviously everyone who uses PyMongo) the tightest.

Your project looks very high quality -- benchmarks, tests, and comparisons are basically an indicator in my mind. Looking through the code you've also already left me (or someone else) space to try doing the SQLite as long as we implement it as an Engine[0] -- am I understanding that right? If I trace the code from database.py to engines/.py it looks like that. I really like the balance you've picked between pragmatism and space for expansion/modification.

A couple questions:

- How do you feel about type annotations in* the code (as opposed to just the comments, as far as I can see)

- PyPy? I wonder if you'd get a ~free speedup

[0]: https://github.com/scottrogowski/mongita/blob/master/mongita...

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#44
post #34

Cool project but I have to admit I sure wish this was written on top of SQLite, rather than just mentioned it, implementing a query language shim for MongoDB on SQLite would be an amazing project. In the absence of such a project though, this is a pretty great alternative to have.

Funny enough I started something like that as a ruby library and stopped when I got to the query language shim because I just ran out of time and motivation. https://github.com/wa9ace/squongo

Thanks for sharing -- yeah honestly I think the shim is the huge chunk of work here -- you would basically become a mongo expert/core comitter at the end of it. The same can be said of SQL but it feels like SQL is a bit less ad hoc (because it is, if only for the amount of committees involved), and there are some libraries that already do the parsing and stuff.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#46

Earlier quoted context omitted.

Everyone is so overly critical in this thread. This is an excellent idea and your library is proof of concept. Surely one day performance can be improved in the future, and the core logic can be rewritten in a compiled language that can be used from other runtimes.

> Everyone is so overly critical in this thread. The main criticism seems to be the flawed connection to sqlite. As useful as Mongita might be, and I don't think anyone is denying that this is good work, it doesn't make sense to compare it to sqlite.

Comparison seems entirely reasonable to me.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#47
post #39

Earlier quoted context omitted.

The project isn't about performance, it's about providing an embedded version of MongoDB - it clearly states that if you grow too large, then you can easily migrate to the full MongoDB. It also clearly states not to use it if you want a relational database.

I am not even sure what is going on now, as I thought the only reason people had ever cared about MongoDB in the first place was in an attempt to get performance they thought was impossible using a relational database (notably without realizing all of the tradeoffs... some inexcusable, such as simply coming with defaults that didn't call fsync, leading to a ton of memes about "database administrators running with sci…

The correct comparison is "Mongita is to MongoDB as SQLite is to Postgres/Mysql".

"performance or scalability" are not benefits of SQLite.

The benefit of SQLite is that it is a "small, fast, self-contained, high-reliability, full-featured, SQL database engine".

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#48
post #36

Earlier quoted context omitted.

Author here. My goal with that one-liner was to convey immediately what it is - an embedded database that implements the PyMongo/MongoDB API. Is it semantically perfect? Probably not. Will Mongita be useful to Python developers who are accustomed to saving their data in idiosyncratic JSON files because they don't want the overhead of a MongoDB server? Maybe! I hope so.

Thanks for sharing your project. It’s probably not a good comparison. SQLite is in such high esteem and such a well developed high quality mature product. So the comparison is sort of inviting criticism that gets in the way of people appreciating what is good about your project.

I am astonished that this is this is the sentiment. I've always of SQLite as a small, self-contained implementation of a SQL DB server. And so the comparison makes perfect sense to me.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#49
post #33

Earlier quoted context omitted.

SQLite is a portable DBMS library that exposes a SQL language interface that is built and runs under every OS and language under the sun, for the most part. It is probably the single-most distributed library on the planet (in aggregate). And likely one of the most used libraries (top 10) on just about every given OS and platform/language. Mongita is only useful for Python developers.

I like sqlite and agree with your it should run everywhere to be compared. I question that it is the most distributed library on the planet. Is there something backing that up? It would be cool but very shocking.

I can't say it's the most, but it does get used a lot. Chromium and descendants, Firefox, bunch of chat apps (Telegram, WeChat), and so on. You probably have multiple copies per machine.

The SQLite people are quite proud of their ubiquity: https://sqlite.org/mostdeployed.html

Post reply on HN