Until now you have used your trusty db.sqlite3 file for all your database needs. And things have gone just fine! So what's the need for suddenly introducing a different database?
You may have guessed it already, and you will hear this more than once as you move towards deploying your apps in the upcoming chapters: Django provides a few convenience tools for local development, that are not meant for running your webapp in production. And yes, using SQLite as your database is one of these conveniences that you will learn to shake off as you move your apps onto the web.
Why Not Use SQLite in Production?
SQLite is a file-based database, which means that the whole database is contained in the one file you've seen sitting right there in your project file system: db.sqlite3. You've experimented with deleting the whole database by simply deleting that one file.
Using a file-based database offers some convenience for development, since you don't need to set up a separate database server. However, it can also be quite slow, as the input/output is restricted to writing and reading from one file object. If you have a small webapp that suddenly grows in popularity, the speed and stability limitations of SQLite could soon become a real problem for your app.
Info: There is no doubt that SQLite is currently used in a ton of production settings. Depending on project requirements and demand, it may be able to do the job just fine. The key is knowing each tool's strengths and weaknesses to ensure that you're choosing an appropriate solution. When in doubt, or if you simply want to follow best practices, choose one of the more robust and scalable options below.
Production-Quality Databases
Production-quality databases are usually server-based databases. While the data is also stored in files, the input/output operations are not performed via simple read/write operations on the file. Instead, there is a server process running that accepts requests and performs actions depending on these requests. You can think of it in a similar way to a webserver, only that in the case of a relational database server, the communication happens via SQL commands.
Your Django app connects to the database server and sends queries to it. The server itself is responsible for updating the database files. These production-quality, server-based databases are built to scale and to perform. They are able to handle a lot of requests securely and quickly.
That's what "production-quality" means, and why you'll want to use a server-based database when running your app in production. Examples for common high-quality server-based relational databases are:
All of these relational database management systems (RDBMS) use their own special flavor of SQL syntax, but otherwise have more or less the same functionality.
In the upcoming part of the course you will learn how to switch your database backend from SQLite to PostgreSQL, the most advanced open-source relational database system, that is also recommended by the Django community.
Summary: What is a Production-Quality Database
- A production-quality database is usually server-based
- SQLite is a file-based: the whole database is contained in a single file
- SQLite will not provide the speed and stability needed in a production environment
- PostgreSQL, MySQL, MariaDB, and Microsoft SQL, are all examples of production-quality, relational databases
- You will train using PostgreSQL when building your second Django Polls app