By Sahidur Pub Feb 20

Part 4: How PostgreSQL Handles Millions of Blog Posts — Without Breaking

A simple explanation of how databases work, why connection pooling matters, and how AllBengal keeps everything fast.

Part 4: How PostgreSQL Handles Millions of Blog Posts — Without Breaking

The Problem: Too Many Readers = Too Slow

Imagine you're a cashier at a store, and suddenly 1,000 people want to check out at the same time. You can't help them all simultaneously. You'd have a line, people would wait, and some might leave frustrated.

Databases have the same problem. When thousands of people read your blog at the same time, they all need data from the database. If it's not set up right, everything slows down.

What Is a Database?

A database is like a library:

  • Books = your blog posts, user accounts, comments, etc.
  • Library card = your login credentials
  • Librarian = the database program (PostgreSQL)
  • Reading room = a connection to the database

When you read a blog post, you're asking the librarian to get it from the shelf. When 1,000 people read posts at the same time, they're all asking the librarian for different books.

The Smart Solution: Connection Pooling

Instead of opening a new connection every time (like hiring a new librarian), I use connection pooling:

Without pooling:
  • Reader 1 arrives → Open connection 1
  • Reader 2 arrives → Open connection 2
  • Reader 3 arrives → Open connection 3
  • ... eventually the database gets exhausted
With pooling:
  • I have 10 ready-made connections sitting idle
  • Reader 1 arrives → Use connection 1
  • Reader 1 finishes → Connection 1 goes back to the pool
  • Reader 2 arrives → Reuse connection 1
  • This way, 10 connections can serve thousands of readers

It's like having 10 librarians instead of 1,000, because readers take turns.

How It Works in AllBengal

// In app/core/database.py
pool = await asyncpg.create_pool(
    host="supabase.postgres.net",
    min_size=2,    // Always keep 2 connections ready
    max_size=10,   // Never create more than 10 connections
)

// When a request comes in:
async with pool.acquire() as connection:
    // Use the connection to fetch data
    posts = await connection.fetch("SELECT * FROM posts")
    // When done, connection automatically goes back to the pool

PostgreSQL: Why This Database?

I chose PostgreSQL because:

  1. It's reliable: Used by Netflix, Spotify, Instagram — companies that handle billions of requests
  2. It's free: Open source, no licensing fees
  3. It scales: Can handle millions of rows efficiently
  4. It's hosted free on Supabase: I don't need to manage servers

Storing Blog Posts: The Schema

Here's how AllBengal stores your posts (simplified):

Column Name What It Stores
id Unique number for each post
title Your blog title
slug URL-safe name like "my-first-post"
content The actual blog post HTML
thumbnail URL to the cover image
author_id Who wrote it
created_at When it was published
updated_at When it was last edited
status Draft or published

When you query for a post by slug:

SELECT * FROM posts WHERE slug = 'my-first-post'

PostgreSQL finds it in milliseconds, even if there are 1 million posts.

Indexing: The Fast Lookup

Databases use indexes like a book's table of contents:

Without index: To find "my-first-post", PostgreSQL reads every single post (slow!)

With index: PostgreSQL jumps straight to the right post (fast!)

AllBengal creates indexes on:

  • slug (to find posts by URL)
  • author_id (to find all posts by one author)
  • created_at (to sort by newest first)

It's like having bookmarks in a giant book — you can jump to the right page instantly.

Async Connections: Super Fast

AllBengal uses async connections, which means:

Old way (blocking):
User 1 requests: "Get me post #5"
Database: "Getting it... (1 second)..."
User 2 requests: "Get me post #3"
Database: "Wait, I'm busy with User 1"
User 2 waits...
New way (async):
User 1 requests: "Get me post #5"
User 2 requests: "Get me post #3"
Database: "I'll start both at the same time"
Both finish in ~1 second instead of 2

It's like a waiter taking multiple orders at once instead of finishing one completely before taking the next.

Real-World Numbers

With AllBengal's setup:

Metric Performance
Response time Most requests finish in 100-500 milliseconds
Concurrent users Can handle 1,000+ simultaneous readers
Storage Can store millions of blog posts
Cost Free tier on Supabase (grows as you scale)

The Free Tier: How Much Can You Store?

Supabase free tier gives you:

  • Database size: Up to 500 MB
  • Concurrent connections: Up to 4
  • That's enough for: Thousands of blog posts + users

When you need more, you upgrade to paid (around $25/month) and get:

  • More storage (5 GB)
  • More connections (20)
  • Better backups

The Bottom Line

PostgreSQL + connection pooling = a database that:

  • ✅ Handles millions of posts
  • ✅ Serves thousands of readers simultaneously
  • ✅ Returns results in milliseconds
  • ✅ Costs nothing to get started
  • ✅ Scales when you grow

You write posts, I make sure they're stored safely and retrieved super-fast.

Want to know something about databases? Drop a question below!

Analytics

Unique visitors

0

Visits

0

Reactions

0

💬 Comments (0)

No comments yet.

💌 Share Your Opinion With Us

📖 Read More Articles

Explore more articles and discover interesting stories from our blog.

View All Articles →