SQLite: यह कब काफ़ी है
VPS पर SQLite अलग डेटाबेस सर्वर से कहाँ बेहतर है, WAL कैसे चालू करें और “database is locked” से कैसे बचें, और PostgreSQL पर कब शिफ़्ट करें।
23 अगस्त 2026 को अपडेट किया गया
SQLite एक फ़ाइल में रहने वाला डेटाबेस है — कोई सर्विस नहीं, कोई पोर्ट नहीं, कोई पासवर्ड नहीं। बॉट, छोटे पैनल या कम लिखावट वाली साइट के लिए यह सही चुनाव है: यह मेमोरी नहीं खाता, और VDS-1 में सिर्फ़ 2 GB ही है, और कॉन्फ़िगर करने के लिए कुछ भी नहीं है।
कब इस्तेमाल करें
अच्छा विकल्प:
- Telegram और Discord बॉट, काउंटर, सेटिंग्स;
- ऐसी साइटें जहाँ प्रति मिनट हज़ारों रीड और दर्जनों राइट होते हैं;
- एक ही मशीन पर चलने वाला कोई भी प्रोजेक्ट जिसमें दूसरे सर्वर की कोई योजना नहीं है।
अच्छा विकल्प नहीं:
- एक साथ कई प्रोसेस का सक्रिय रूप से लिखना;
- कुछ दर्जन गीगाबाइट से बड़ा डेटाबेस;
- किसी दूसरी मशीन से नेटवर्क एक्सेस — SQLite यह कर ही नहीं सकता।
दूसरे और तीसरे मामले में PostgreSQL या MySQL इस्तेमाल करें।
फ़ाइल के साथ काम करना
apt install -y sqlite3
sqlite3 /srv/app/data/app.db
CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
INSERT INTO users (name) VALUES ('test');
.tables
.schema users
.quit
डेटाबेस फ़ाइल मशीन की लोकल डिस्क पर होनी चाहिए और उसका मालिक एप्लिकेशन यूज़र होना चाहिए:
chown appuser:appuser /srv/app/data/app.db
chmod 640 /srv/app/data/app.db
जिस डायरेक्टरी में डेटाबेस है, वह भी लिखने योग्य होनी चाहिए: SQLite उसके बगल में अस्थायी -wal और -shm फ़ाइलें बनाता है।
ज़रूरी सेटिंग्स
दो pragma सेटिंग्स ज़्यादातर समस्याएँ खत्म कर देती हैं:
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
WAL की मदद से रीडर तब भी पढ़ सकते हैं जब कोई राइट चल रहा हो — इसके बिना कोई भी रीडर राइटर से ब्लॉक हो जाता है। busy_timeout क्लाइंट को तुरंत फ़ेल होने के बजाय पाँच सेकंड इंतज़ार कराता है। इन्हें कोड में हर बार कनेक्शन खोलते समय सेट करें, कंसोल में एक बार नहीं।
बैकअप
एप्लिकेशन चलते समय आप सादे cp से फ़ाइल कॉपी नहीं कर सकते — इससे डेटाबेस खराब हो जाएगा। एक बिल्ट-इन सुरक्षित कमांड है:
sqlite3 /srv/app/data/app.db ".backup '/srv/backups/app-$(date +%F).db'"
इसे cron में डालें और कॉपी को मशीन से बाहर ले जाएँ: VPS में न ऑटोमैटिक बैकअप हैं और न ही स्नैपशॉट। सामान्य तरीका डेटाबेस बैकअप में बताया गया है।
आम एरर
| लक्षण | कारण |
|---|---|
database is locked | WAL या busy_timeout नहीं है, या कोई दूसरा प्रोसेस लंबा ट्रांज़ैक्शन पकड़े हुए है |
attempt to write a readonly database | फ़ाइल या डायरेक्टरी पर परमिशन नहीं है |
disk I/O error | डिस्क स्पेस खत्म — “Overview” में डिस्क यूसेज रिंग देखें |
| पंक्तियाँ हटाने के बाद डेटाबेस बढ़ता है | स्पेस अपने आप नहीं छूटता: VACUUM |
| कॉपी करने के बाद डेटाबेस खराब | आपने चलते समय cp से कॉपी किया — सिर्फ़ .backup इस्तेमाल करें |
कब माइग्रेट करें
संकेत: WAL चालू होने पर भी नियमित रूप से database is locked एरर आना, कई एप्लिकेशन वर्कर, ऐसी रिपोर्ट जिन्हें बनाने में कई मिनट लगते हैं। शिफ़्ट करने के लिए डेटाबेस माइग्रेशन देखें।
डेटाबेस फ़ाइल ऐसी डायरेक्टरी में नहीं होनी चाहिए जिसे वेब सर्वर सर्व करता हो।
/var/www/app.dbको डायरेक्ट लिंक से डाउनलोड किया जा सकता है, साथ में सारे पासवर्ड और यूज़र डेटा भी।