This page describes some popular third-party libraries for working with PyMongo. With the exception of Motor, all libraries on this page are maintained by the community. To keep this list current, projects that haven't been updated recently will occasionally be removed from the list or moved to the end.
TipAlthough these libraries can be helpful, we recommend that new PyMongo users begin by working directly with the driver. PyMongo alone will meet most people's needs, and working with it is instructive in how MongoDB works.
ORM-like (object-relational-mapping-like) layers add features like models and validation to PyMongo.
MincePy is an object-document mapper (ODM) designed to make any Python object storable and queryable in a MongoDB database. It was designed with machine learning and big-data computational and experimental science applications in mind. However, it's entirely general and can be useful to anyone looking to organize, share, or process large amounts of data with as little change to their current workflow as possible.
Ming is a library that allows you to enforce schemas on a MongoDB database in your Python application. It was developed by SourceForge in the course of their migration to MongoDB. See the introductory blog post for more details.
MongoEngine lets you use syntax inspired by the Django ORM to define schemas for documents and query collections. The code is available on GitHub.
MotorEngine is a port of MongoEngine to Motor, allowing asynchronous access with Tornado. It implements the same modeling APIs in a data-portable way, meaning that a model defined in MongoEngine can be read in MotorEngine. The source is available on GitHub.
uMongo is a Python MongoDB ODM that was created to meet two needs: the lack of an asynchronous ODM and the difficulty of serializing documents with other ODMs. uMongo works with multiple drivers: PyMongo, TxMongo, motor_asyncio, and mongomock. The source is available on GitHub.
This section lists tools and adapters that have been designed to work with various Python frameworks and libraries.
You can use the official Django MongoDB Backend to use MongoDB as your database in Django applications. Django MongoDB Backend is a Django database backend that uses PyMongo to connect to MongoDB. By using the backend, you can use Django models to represent MongoDB documents, with support for Django forms, validations, and authentication. Django MongoDB Backend also enables you to use MongoDB-specific querying optimizations in your applications, such as aggregation operations and indexes.
Important Public PreviewDjango MongoDB Backend is in Public Preview and intended for evaluation purposes only. Public Preview is not recommended for production deployments, as breaking changes may be introduced. To learn more, see Preview Features.
Flask-MongoAlchemy adds Flask support for MongoDB with MongoAlchemy.
Flask-MongoKit is a Flask extension to better integrate MongoKit into Flask.
Flask-PyMongo bridges Flask and PyMongo.
Full Stack FastAPI App Generator enables you to quickly spin up a full-stack application that integrates FastAPI, React, and MongoDB.
Log4Mongo is a flexible Python logging handler that can store logs in MongoDB by using normal and capped collections.
mongobox is a tool to run a sandboxed MongoDB instance from within a Python app.
mongodb_beaker enables you to use MongoDB as a backend for Beaker's caching and session system. The source is on GitHub.
MongoLog is a Python logging handler that stores logs in MongoDB by using a capped collection.
rod.recipe.mongodb is a Buildout recipe for downloading and installing MongoDB.
This section lists tools that support interopability with other tools.
PyMongo uses thread and socket functions from the Python standard library. By using gevent , PyMongo can do asynchronous I/O with non-blocking sockets and schedule operations on greenlets instead of threads.
To use gevent with PyMongo, call gevent's monkey.patch_all() method before loading any other modules, as shown in the following example:
from gevent import monkey_ = monkey.patch_all()from pymongo import MongoClientclient = MongoClient()If you call monkey.patch_all() when your application launches, MongoClient will use greenlets instead of threads to monitor the health of the server. When shutting down, if your application calls the ~gevent.hub.Hub.join() method without first terminating these greenlets, the call to the ~gevent.hub.Hub.join() method blocks indefinitely.
To avoid this, close or dereference any active MongoClient objects before exiting your application. In some application frameworks, you can use a signal handler to end background greenlets when your application receives SIGHUP, as shown in the following example:
import signaldef graceful_reload(signum, traceback): """Explicitly close some global MongoClient object.""" client.close()signal.signal(signal.SIGHUP, graceful_reload)This issue affects applications using uWSGI versions earlier than 1.9.16 or newer uWSGI versions with the -gevent-wait-for-hub option. For more information, see the uWSGI changelog.
The mod_wsgi package provides an Apache module that implements a WSGI-compliant interface for hosting Python-based web applications on top of the Apache web server.
To run your PyMongo application under mod_wsgi, follow these guidelines:
Use the WSGIDaemonProcess directive to run mod_wsgi in daemon mode. If your mod_wsgi configuration includes only the WSGIScriptAlias directive, it will run in embedded mode.
Use the WSGIApplicationGroup %{GLOBAL} directive to ensure your application runs in the daemon's main Python interpreter, rather than a sub-interpreter. This avoids a small cost incurred when decoding BSON in a sub-interpreter.
Use the WSGIProcessGroup directive to assign each application to a separate daemon. This ensures the applications don't affect each other's state.
The following mod_wsgi configuration shows how to use the preceding directives to run your PyMongo application:
<VirtualHost *> WSGIDaemonProcess my_process WSGIScriptAlias /my_app /path/to/app.wsgi WSGIProcessGroup my_process WSGIApplicationGroup %{GLOBAL}</VirtualHost>If you have multiple PyMongo applications, put each in a separate daemon in the global application group:
<VirtualHost *> WSGIDaemonProcess my_process WSGIScriptAlias /my_app /path/to/app.wsgi <Location /my_app> WSGIProcessGroup my_process </Location> WSGIDaemonProcess my_other_process WSGIScriptAlias /my_other_app /path/to/other_app.wsgi <Location /my_other_app> WSGIProcessGroup my_other_process </Location> WSGIApplicationGroup %{GLOBAL}</VirtualHost>Many Python C extensions have issues when running in multiple Python sub-interpreters. These difficulties are explained in the documentation for Py_NewInterpreter and in the Multiple Python Sub Interpreters section of the mod_wsgi documentation.
For a list of tools that can use type hints to detect errors in your code, see Static Typing with Python in the typing module documentation.
The default values for generic document types are not yet available in Mypy. For a discussion of the Mypy limitations that caused this issue, see the Mypy GitHub repository.
If you're using Mypy and want to opt out of using the provided types, add the following lines to your Mypy configuration file:
[mypy-pymongo]follow_imports = FalseThis section lists alternatives to PyMongo.
Motor is a full-featured, non-blocking MongoDB driver for Python Tornado applications.
TxMongo is an asynchronous Twisted Python driver for MongoDB.
MongoMock is a small library to help test Python code. It uses PyMongo to interact with MongoDB.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4