Creating tables (db.create_all) in Flask - Performance Optimization Steps

Performance: Creating tables (db.create_all)

MEDIUM IMPACT

This affects the initial page load time and backend response speed when the database tables are created or checked.

Creating database tables in a Flask app

Flask

from flask import Flask
from flask_sqlalchemy import SQLAlchemy

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'
db = SQLAlchemy(app)

with app.app_context():
    db.create_all()

@app.route('/')
def index():
    return 'Hello World!'

if __name__ == '__main__':
    app.run()

Creating tables once during app startup avoids blocking requests and improves response speed.

📈 Performance GainNo blocking during requests, reducing LCP by 100-300ms on first load.

Creating database tables in a Flask app

Flask

from flask import Flask
from flask_sqlalchemy import SQLAlchemy

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'
db = SQLAlchemy(app)

@app.route('/')
def index():
    db.create_all()
    return 'Hello World!'

if __name__ == '__main__':
    app.run()

Calling db.create_all inside a route blocks the request until tables are created, causing slow response and poor user experience.

📉 Performance CostBlocks rendering for 100-300ms on first request, increasing LCP and delaying page load.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
db.create_all inside route	N/A (server-side)	N/A	Blocks response, delays paint	[X] Bad
db.create_all at startup	N/A (server-side)	N/A	Non-blocking response, faster paint	[OK] Good

Rendering Pipeline

Table creation happens on the server side before sending the response. If done during a request, it delays the server response, increasing time to first byte and LCP.

→Server Processing

→Network Transfer

→Browser Rendering

⚠️ BottleneckServer Processing (blocking db.create_all call)

Core Web Vital Affected

LCP

This affects the initial page load time and backend response speed when the database tables are created or checked.

Optimization Tips

1Run db.create_all once during app startup, not inside request handlers.

2Avoid blocking operations during request processing to improve LCP.

3Use app.app_context() when creating tables outside routes.

Performance Quiz - 3 Questions

What is the main performance issue with calling db.create_all inside a Flask route?

A It blocks the server response, increasing page load time

B It increases client-side rendering time

C It causes excessive DOM reflows

D It increases CSS selector complexity

DevTools: Network

How to check: Open DevTools, go to Network tab, reload page, and check the time for the first request to the server.

What to look for: Look for long server response time (TTFB) indicating blocking operations like db.create_all during request.

Practice

1. What does the db.create_all() function do in a Flask application?

easy

A. It updates existing tables to match model changes automatically.

B. It deletes all tables from the database.

C. It creates all tables defined by your models in the database if they don't exist.

D. It runs all database queries defined in your app.

Solution

1. Step 1: Understand the purpose of db.create_all()

   This function creates tables in the database based on your model definitions if those tables do not already exist.

2. Step 2: Recognize what it does not do

   It does not delete tables, update existing tables, or run queries; it only creates missing tables.

3. Final Answer:

   It creates all tables defined by your models in the database if they don't exist. -> Option C

4. Quick Check:

   db.create_all() creates missing tables [OK]

Hint: Remember: create_all only adds missing tables, no updates [OK]

Common Mistakes:

• Thinking it updates existing tables automatically
• Confusing it with deleting tables
• Assuming it runs queries or migrations

2. Which of the following is the correct way to use db.create_all() in a Flask app?

easy

A. Call db.create_all() inside the Flask app context.

B. Call db.create_all() after closing the app.

C. Call db.create_all() before defining your models.

D. Call db.create_all() outside the Flask app context.

Solution

1. Step 1: Understand Flask app context requirement

   Database operations like db.create_all() must run inside the Flask app context to access configuration and database connections properly.

2. Step 2: Identify correct usage

   Calling db.create_all() inside the app context ensures tables are created without errors.

3. Final Answer:

   Call db.create_all() inside the Flask app context. -> Option A

4. Quick Check:

   db.create_all() requires app context [OK]

Hint: Always run db.create_all() inside app context [OK]

Common Mistakes:

• Calling create_all outside app context causing errors
• Calling create_all before models are defined
• Calling create_all after app is closed

3. Given this Flask code snippet, what will happen when db.create_all() is called?

from flask import Flask
from flask_sqlalchemy import SQLAlchemy

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'
db = SQLAlchemy(app)

class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(50))

with app.app_context():
    db.create_all()

medium

A. An error will occur because the app context is missing.

B. A new table named 'user' will be created in the database if it doesn't exist.

C. The existing 'user' table will be dropped and recreated.

D. Nothing happens because create_all does not create tables.

Solution

1. Step 1: Check app context usage

   The code calls db.create_all() inside app.app_context(), so the context is correct.

2. Step 2: Understand create_all behavior

   It creates missing tables based on models. Since 'User' model exists, a 'user' table will be created if not present.

3. Final Answer:

   A new table named 'user' will be created in the database if it doesn't exist. -> Option B

4. Quick Check:

   create_all creates missing tables inside app context [OK]

Hint: create_all adds missing tables, does not drop existing [OK]

Common Mistakes:

• Thinking create_all drops tables
• Forgetting app context causes errors
• Assuming create_all does nothing

4. You run db.create_all() but your new model's table is not created. What is the most likely cause?

medium

A. All of the above.

B. You defined the model after calling db.create_all().

C. The database URI is incorrect or missing.

D. You forgot to run db.create_all() inside the Flask app context.

Solution

1. Step 1: Check app context usage

   Running db.create_all() outside app context causes tables not to be created.

2. Step 2: Check model definition timing and database URI

   If models are defined after calling db.create_all(), their tables won't be created. Also, an incorrect or missing database URI prevents connection.

3. Final Answer:

   All of the above. -> Option A

4. Quick Check:

   App context, model timing, and URI all affect create_all success [OK]

Hint: Check app context, model order, and DB URI if tables missing [OK]

Common Mistakes:

• Ignoring app context errors
• Calling create_all before defining models
• Not setting database URI correctly

5. You want to add a new column to an existing table after calling db.create_all(). What will happen if you call db.create_all() again without migrations?

hard

A. An error will occur because the table schema changed.

B. The new column will be added automatically to the existing table.

C. The existing table will be dropped and recreated with the new column.

D. Nothing changes; db.create_all() does not modify existing tables.

Solution

1. Step 1: Understand create_all limitations

   db.create_all() only creates missing tables; it does not alter existing tables or add columns.

2. Step 2: Recognize need for migrations

   To change existing tables (like adding columns), you must use migration tools such as Flask-Migrate.

3. Final Answer:

   Nothing changes; db.create_all() does not modify existing tables. -> Option D

4. Quick Check:

   create_all creates tables but does not alter existing ones [OK]

Hint: Use migrations to change tables; create_all only adds missing tables [OK]

Common Mistakes:

• Expecting create_all to update tables
• Not using migration tools for schema changes
• Assuming create_all drops and recreates tables