PostBlob 🐘

PostgreSQL Does Everything™ - A web framework where the database IS the application

PostBlob is an experimental web framework that pushes PostgreSQL to its absolute limits. Instead of using the database as just a data store, PostBlob makes PostgreSQL handle EVERYTHING: HTTP routing, HTML rendering, file storage, job queuing, session management, and even code hot-reloading.

🤯 What Makes This Special?

• The entire application logic lives in PostgreSQL - The Python server is just 345 lines of glue code
• Hot deployment without restarts - Modify functions while the server is running (ACID deploys!)
• Self-modifying code - Functions stored in database tables can rewrite themselves
• Natural language SQL queries - Ask "show code" and get actual results
• Database-powered code editor - Web UI that modifies its own source code
• Everything is a transaction - Deploy, rollback, or test changes atomically

🚀 Quick Start

# Clone the repository
git clone https://github.com/yourusername/postblob.git
cd postblob

# Create Python virtual environment
python -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

# Install dependencies (just psycopg2!)
pip install -r requirements.txt

# Create the database
createdb postblob

# Initialize PostBlob
python server.py init

# Start the server
python server.py server --port 8002

# Visit http://localhost:8002

🎮 Process Management

PostBlob includes a process manager with PID file tracking:

# Start server
./postblob_ctl.py start --port 8002

# Check status
./postblob_ctl.py status

# Backup database
./postblob_ctl.py backup

# Restore from backup
./postblob_ctl.py restore postblob_backup.sql

# Restart server
./postblob_ctl.py restart postblob_8002.pid

# Stop all processes
./postblob_ctl.py stop --all

🔥 Features

Hot Deploy Code Editor

Visit /code to modify any function while the server is running. Changes are applied instantly without restarts.

Natural Language Queries

The /ask endpoint understands queries like:

• show code - List all stored functions
• show blobs - Display uploaded files
• failed jobs - Show failed background jobs
• show helpers - List utility functions

Built-in Helper Functions

PHP-style web helpers implemented in PL/pgSQL:

• html_encode() / html_decode()
• url_encode() / url_decode()
• slugify() - Create URL-friendly slugs
• parse_query_string() - Parse URL parameters
• format_bytes() - Human-readable file sizes
• random_string() - Generate tokens
• And more!

Everything is Stored in PostgreSQL

-- Tables that power the application
blobs          -- File uploads stored as bytea
jobs           -- Background job queue
sessions       -- User sessions
cache          -- Key-value cache
exceptions     -- Error tracking
code_files     -- All functions stored here!
code_history   -- Version control for functions

📁 Project Structure

postblob/
├── server.py              # Minimal Python server (345 lines)
├── init_postblob_simple.sql  # Database schema
├── hot_deploy.sql         # Code hot-reload system
├── natural_sql.sql        # Natural language queries
├── helper_functions.sql   # Web utility functions
├── postblob_ctl.py       # Process manager
└── README.md             # You are here

🧪 How It Works

1. HTTP Request → Python server receives request
2. PostgreSQL Function Call → handle_request() is called with method, path, headers, body
3. Routing in SQL → CASE statements match paths and methods
4. Response Generation → PostgreSQL returns JSON with status, headers, and body
5. Python Returns Response → Thin wrapper sends response back to client

The Python server is essentially just:

response = db.execute("SELECT handle_request(%s, %s, %s, %s)",
                      (method, path, headers, body))
return response

🎯 Use Cases

PostBlob is perfect for:

• Learning - Explore PostgreSQL's advanced features
• Prototyping - Rapidly build database-backed applications
• Experimentation - Push boundaries of what databases can do
• Fun - Because why not make PostgreSQL do everything?

PostBlob is NOT recommended for:

• Production systems (seriously, don't)
• High-performance applications
• Applications requiring complex client-side interactions
• Anything where "because we can" isn't a valid architectural decision

🛠️ Development

Adding New Routes

Edit the handle_request() function via the web UI at /code:

WHEN p_path = '/my-route' AND p_method = 'GET' THEN
    RETURN jsonb_build_object(
        'status', 200,
        'body', jsonb_build_object('message', 'Hello!')
    );

Creating Background Jobs

INSERT INTO jobs (type, payload)
VALUES ('send_email', '{"to": "user@example.com"}');

Hot Reload Functions

SELECT hot_reload('functions/my_function.sql');

🤔 Philosophy

PostBlob asks the question: "What if we took the 'database-driven' architecture to its logical extreme?"

Instead of:

• ORM: Object → SQL → Database
• PostBlob: SQL → SQL → SQL

This is both a love letter to PostgreSQL's power and a cautionary tale about taking ideas too far.

⚠️ Warnings

• This is experimental software
• Not suitable for production use
• May cause confusion among your DBA friends
• Side effects may include an irresistible urge to implement entire applications in SQL

📄 License

MIT License - See LICENSE file for details

🤝 Contributing

Contributions are welcome! Feel free to:

• Add more helper functions
• Improve the natural language query parser
• Create new self-modifying function examples
• Write tests (in SQL, naturally)
• Question our sanity

🙏 Acknowledgments

• PostgreSQL developers for making this insanity possible
• Everyone who said "you can't build a web app entirely in PostgreSQL" (you were right, but we did it anyway)
• Coffee, lots of coffee

🎪 Fun Facts

• The code editor can edit itself
• Functions can rewrite themselves while running
• The homepage is a 400-line FORMAT() statement
• Deployments are ACID-compliant database transactions
• The Python "server" knows nothing about the application logic

---

Remember: Just because you can doesn't mean you should. But sometimes, you should anyway.

🐘 PostBlob - PostgreSQL Does Everything™