Moving forward from Django Non-Rel

Background

Django is a free and open-source, Python-based web framework that follows the model–template–views (MTV) architectural pattern. Django's primary goal is to ease the creation of complex, database-driven websites. The framework emphasizes reusability of components, less code, low coupling, rapid development, and the principle of don't repeat yourself.

Django can manipulate databases using two standard methods: SQL and ORM, where:

  • SQL (Structured Query Language) is the native language of most databases. While a standard, each database engine does have its own flavor.

  • ORM (Object-Relational Mapping) is a standardized, object-oriented "interpreter" built atop a choice of several different database engine SQL flavors. It enables the same application code to manipulate different underlying database engines. The ORM is Django's preferred database access method.

Click to enlarge

The Problem

But, Django does not support the non-relational, no-SQL Google BigTable database, hence the creation of Django Non-Rel, used by various projects started back in the 2010 timeframe. Django Non-Rel was a non-sanctioned spin-off from Django version 1.x circa 2010, built on Python 2.

Never supported by the Django project or Google, Django Non-Rel was long ago abandoned by developers.

Today

But, Django standard development is very active. The latest version 4, was built with the latest version of Python 3, and is fully supported by Google and others on multiple database engines. Let’s look at the latest Django more closely:

  1. If you stay with Django, you should use its ORM (why later) with a relational, SQL database. That will narrow your database engine choices.

  2. The ORM is Django's preferred database access method. In addition to database engine independence, it offers these additional advantages, and more (see Pros and Cons section). But, it doesn't support every database engine out there. Officially supported, by the Django project:

    • PostgreSQL

    • MariaDB

    • MySQL

    • Oracle

    • SQLite

    Unofficially supported, by third parties:

    • CockroachDB

    • Firebird

    • Google Cloud Spanner

    • Microsoft SQL Server

    In general, we want to avoid (A) unofficially supported and (B) proprietary solutions.

  3. The following Cloud database engines are also supported:

  1. Google

    1. PostgreSQL

    2. MySQL

  2. Azure

    1. All Google choices

    2. MariaDB

  3. AWS

    • All Azure choices

    • Oracle

If you use the Django ORM, and you should, you can base your choice on feature set, price, preference, cloud platform brand, or other factors. The database independence of the Django ORM enables you to switch database engines later without changing your application code. That's powerful!

All that said…

Googling best database for Django indicates the Django community and docs prefer PostgreSQL. Indeed, PostgreSQL has a number of features which are not shared by the other databases Django supports. More reasons to choose PostgreSQL. I've successfully used MySQL with Django, but given this new information I'm likely to choose PostgreSQL next time. 

Source: https://www.finitewisdom.com/people/richar...