VPS वर SQLite production database म्हणून कधी वापरावे?

VPS वर SQLite हे production database म्हणून योग्य कधी ठरते

लहान अॅप्लिकेशन्ससाठी VPS वरील production environment मध्ये SQLite वापरणे योग्य ठरते. कारण सोपे आहे: एका मशीनवर चालणाऱ्या एका process कडून एका file मध्ये लेखन होत असेल, तर स्वतंत्र database server ची गरज नसते. देखरेख करण्यासाठी daemon नसतो, firewall मध्ये उघडा ठेवण्यासाठी port नसतो, नियमितपणे बदलण्यासाठी password नसतो आणि चालू ठेवण्यासाठी दुसरी मशीन नसते. Query ही network round trip ऐवजी function call असते. त्यामुळे एका page वर चाळीस queries चालत असतील, तर त्यासाठी चाळीस function calls होतात.

याची मर्यादा स्पष्ट आणि वास्तविक आहे. संपूर्ण database file साठी एका वेळी फक्त एक writer असू शकतो. तसेच ही file दोन machines मध्ये share करता येत नाही. एकाच VPS वर एकच अॅप्लिकेशन चालत असल्यास या दोन्ही मर्यादा स्वीकारता येतात. मात्र या रचनेच्या पलीकडे गेल्यावर दोन्ही मर्यादा गंभीर ठरतात. या मार्गदर्शिकेत server वर SQLite सुरक्षित ठेवण्यासाठी आवश्यक settings, Litestream वापरून continuous backup आणि SQLite कधी वापरणे थांबवावे हे समाविष्ट आहे.

सर्वप्रथम command line tool install करा. खालील सर्व commands Ubuntu 24.04 वर चालवण्यात आले आहेत.

sudo apt update
sudo apt install -y sqlite3
sqlite3 --version

यामुळे 3. ने सुरू होणारी version, त्यानंतर build date आणि source hash छापला जातो. July 2026 पर्यंत Ubuntu 24.04 मध्ये SQLite 3.45.1 उपलब्ध आहे. तुमच्या अॅप्लिकेशनकडून हे binary वापरले जाण्याची शक्यता कमी आहे. बहुतेक language runtimes मध्ये SQLite library ची स्वतंत्र copy समाविष्ट असते. ती अनेकदा यापेक्षा नवीन असते. त्यामुळे अलीकडील feature वर अवलंबून राहण्यापूर्वी तुमचा database driver कोणती version दाखवतो ते तपासा.

WAL mode मध्ये सर्वप्रथम बदल का करावा

मुलभूतपणे SQLite rollback journal वापरते. एखादे page बदलण्यापूर्वी ते मूळ page एका -journal फाइलमध्ये कॉपी करते आणि त्यानंतर database मध्ये थेट बदल करते. हे सुरक्षितपणे करण्यासाठी संपूर्ण फाइलवर exclusive lock घेतला जातो. त्यामुळे कोणतेही write सुरू असताना प्रत्येक reader प्रतीक्षा करतो. लॅपटॉपवर हे लक्षात येत नाही. Web server वर database ला स्पर्श करणाऱ्या प्रत्येक request ला एखाद्या धीम्या write मुळे विलंब होतो.

WAL (write-ahead log) mode मध्ये ही क्रमवारी उलटते. Writer नवीन pages स्वतंत्र -wal फाइलमध्ये जोडतो आणि मुख्य database मध्ये बदल करत नाही. Readers त्यांनी सुरू केलेल्या snapshot वरील मुख्य फाइल वाचत राहतात. त्यामुळे readers writer ला block करत नाहीत आणि writer readers ना block करत नाही. नंतर checkpoint संकलित WAL pages मुख्य database मध्ये कॉपी करतो. या एका बदलामुळे web application मागे SQLite वापरणे बहुतेक वेळा व्यवहार्य होते.

WAL मोड सुरू करा आणि तो कायम राहिला आहे याची खात्री करा

mkdir -p ~/app
sqlite3 ~/app/app.db "PRAGMA journal_mode=WAL;"

कमांड wal छापते. हे आउटपुट केवळ सजावटीसाठी नाही. PRAGMA journal_mode डेटाबेस सध्या प्रत्यक्षात कोणत्या मोडमध्ये आहे ते परत करते. त्यामुळे delete असे उत्तर मिळाल्यास बदल अयशस्वी झाला आहे आणि तुम्ही अजूनही rollback journal वर आहात.

WAL मोड कायमस्वरूपी असतो. तो connection setting नसून database header मधील flag असतो. त्यामुळे प्रत्येक database file साठी ही कमांड एकदाच चालवावी लागते. त्यानंतरचे प्रत्येक connection, reboot नंतरचे connection देखील, हा मोड आपोआप वापरते. नवीन connection वापरून हे सिद्ध करा.

sqlite3 ~/app/app.db "PRAGMA journal_mode;"

आता table तयार करा आणि disk वर काय दिसते ते पाहा.

sqlite3 ~/app/app.db <<'SQL'
CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL);
INSERT INTO notes (body) VALUES ('first row');
SQL
ls -l ~/app/

आता तीन files आहेत: app.db, app.db-wal आणि app.db-shm. -wal file मध्ये अजून checkpoint न केलेले committed pages असतात. -shm file हा shared memory index असतो. प्रत्येक connection हा index map करते, त्यामुळे WAL मध्ये काय आहे याबाबत सर्व connections एकमताने काम करतात. या दोन्ही files database चाच भाग आहेत; त्या scratch files नाहीत. Application सुरू असताना फक्त app.db ची copy केल्यास अलीकडील प्रत्येक commit गहाळ असलेली file मिळते. app.db delete करून उरलेल्या दोन files तशाच ठेवल्यास SQLite त्या जुन्या WAL pages ला त्या नावाखाली नव्याने तयार होणाऱ्या कोणत्याही file वर लागू करेल. अशा प्रकारे database reset करण्याचा प्रयत्न करताना fresh database corrupt होऊ शकतो.

प्रत्येक production अॅपला आवश्यक असणाऱ्या connection settings

फक्त journal_mode database मध्ये साठवले जाते. खालील इतर प्रत्येक setting ही प्रति-connection असते. त्यामुळे application ने ती उघडलेल्या प्रत्येक connection वर लागू केली पाहिजे. Pool ने background मध्ये तयार केलेल्या प्रत्येक connection वरही ती लागू केली पाहिजे.

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;

busy_timeout = 5000 मुळे locked database साठी SQLite जास्तीत जास्त 5000 milliseconds पर्यंत पुन्हा प्रयत्न करत राहते. त्यानंतर ते database is locked परत करते. Default मूल्य 0 आहे. त्यामुळे दोन writers च्या operations एकाच वेळी झाल्या, तर SQLite पहिल्याच वेळी लगेच अपयशी ठरते. हे एकच मूल्य सेट केल्यास SQLite मुळे होतात असे समजल्या जाणाऱ्या बहुतांश lock errors दूर होतात.

WAL mode मध्ये synchronous = NORMAL ही योग्य setting आहे. मात्र त्यातील trade-off समजून घेणे आवश्यक आहे. FULL असताना प्रत्येक commit वेळी SQLite WAL वर fsync कॉल करते. NORMAL असताना ते checkpoints च्या वेळी sync करते. यामुळे काय गमावले जाते हे SQLite documentation स्पष्टपणे सांगते: power failure किंवा hard reset झाल्यानंतर transactions durable राहत नाहीत. त्या power loss मुळे database corrupt होत नाही. Disk वर पोहोचलेले नसलेले शेवटचे commits मात्र गमावले जातात. VPS वर हा trade-off सहसा योग्य ठरतो, कारण प्रत्येक write च्या मार्गातून fsync काढून टाकला जातो.

foreign_keys = ON हे backwards compatibility साठी default ने off असते आणि प्रति-connection असते. Schema मध्ये अनेक REFERENCES clauses असले, तरी प्रत्येक connection ने ही setting on करेपर्यंत त्यांची कोणतीही अंमलबजावणी होत नाही.

आणखी एक setting नंतर महत्त्वाची ठरते. WAL 1000 pages पेक्षा मोठा झाल्यावर SQLite आपोआप checkpoints करते. त्या वेळी transaction पूर्ण करणारे कोणतेही connection हे काम करते. स्वतंत्रपणे पाहता ही व्यवस्था योग्य आहे. मात्र Litestream चालू असताना हा प्रश्न निर्माण होतो, कारण checkpoints कधी घ्यायचे यावर Litestream ला नियंत्रण हवे असते.

busy_timeout सेट केल्यानंतरही database is locked का होते

हीच त्रुटी लोकांना Postgres कडे परत पाठवते आणि तिचे एक विशिष्ट कारण आहे.

busy timeout सेट केल्यावर busy handler स्थापित होतो; परंतु SQLite तो handler चालवेलच असे आश्वासन देत नाही.

busy handler चालवल्यामुळे deadlock होण्याची शक्यता आहे असे SQLite ला वाटल्यास, busy handler चालवण्याऐवजी ते अनुप्रयोगाला SQLITE_BUSY परत करते.

तो टाळत असलेला deadlock transaction upgrade होताना उद्भवतो. SQLite मधील साधा BEGIN म्हणजे BEGIN DEFERRED. त्यानंतरचे पहिले statement SELECT असल्यास, तुम्ही read transaction मध्ये असता. त्याच transaction मधील नंतरचा UPDATE write transaction मध्ये upgrade होण्याची गरज असताना, आणि तुमचे read सुरू झाल्यानंतर दुसऱ्या connection ने write केलेले असल्यास, SQLite तुम्हाला प्रतीक्षा करू देऊ शकत नाही. तुमचा snapshot आधीच जुना झालेला असतो आणि प्रतीक्षा केल्यास दोन्ही connections एकमेकांविरुद्ध deadlock मध्ये अडकतील. Documentation मध्ये परिणाम थेट सांगितला आहे:

त्यानंतरची write statements शक्य असल्यास transaction ला write transaction मध्ये upgrade करतात; अन्यथा SQLITE_BUSY परत करतात.

तुमचा 5000 millisecond timeout तपासलाच जात नाही. Error लगेच येतो. त्यामुळे setting लागू झाली नाही असे दिसते.

यावरचा उपाय एका शब्दात आहे.

BEGIN IMMEDIATE;
UPDATE notes SET body = 'edited' WHERE id = 1;
COMMIT;

BEGIN IMMEDIATE सुरुवातीपासून write lock घेतो, म्हणजे काहीही read करण्यापूर्वी. त्यामुळे upgrade होत नाही आणि टाळण्यासारखा deadlockही राहत नाही. परिणामी busy handler लागू होतो आणि connection fail होण्याऐवजी आपली पाळी येईपर्यंत प्रतीक्षा करते. Read-only transactions deferred ठेवा. Write असलेला कोणताही transaction immediate असावा.

Lock errors चे दुसरे कारण शोधणे अधिक कठीण असते: slow work चालू असताना write transaction उघडा ठेवणे. SQLite writers चे serialization करते. त्यामुळे transaction उघडून network वर external API call करून नंतर commit केल्यास, त्या call च्या संपूर्ण कालावधीत इतर प्रत्येक writer block होतो. आवश्यक data read करा, transaction बंद करा, slow work करा, आणि नंतर result साठवण्यासाठी छोटा write transaction उघडा.

Litestream सह अखंड बॅकअप

दररोज रात्री घेतलेल्या प्रतीमुळे एक दिवसापर्यंतचे writes गमावले जाऊ शकतात. तसेच, वापरात असलेल्या SQLite database वर cp चालवल्यास तयार झालेली प्रत उघडणार नाही. दोन पद्धती सुरक्षित आहेत. sqlite3 app.db ".backup /path/to/backup.db" SQLite च्या online backup interface चा वापर करते आणि वापरात असलेल्या database वर कार्य करते. Litestream यापेक्षा पुढे जाते: ते WAL वर लक्ष ठेवते आणि बदल object storage वर अखंडपणे अपलोड करते. त्यामुळे सर्वाधिक संभाव्य data loss एक दिवसावरून सुमारे एका सेकंदापर्यंत कमी होते.

Litestream ही तुमच्या application च्या बाजूला चालणारी एक Go binary आहे. ती application आणि database यांच्या मध्ये बसत नाही. तुमचे application पूर्वीप्रमाणेच SQLite मध्ये writes करते. Litestream WAL वाचते आणि झालेले बदल अपलोड करते.

cd /tmp
curl -fsSL -O https://github.com/benbjohnson/litestream/releases/download/v0.5.14/litestream-0.5.14-linux-x86_64.deb
sudo dpkg -i litestream-0.5.14-linux-x86_64.deb
litestream version

जुलै 2026 पर्यंतच्या अधिकृत Linux install page मध्ये v0.5.14 ही release नमूद आहे. 21 July 2026 रोजी v0.5.15 release झाली. releases page वरील सध्याच्या tag शी जुळण्यासाठी दोन्ही ओळींमधील version बदला. तुमचा VPS arm64 असल्यास त्याऐवजी त्याच version चे arm64 package घ्या.

Configuration file /etc/litestream.yml येथे असते. सुरुवात local file replica पासून करा. त्यामुळे cloud credentials शिवाय संपूर्ण प्रक्रिया कार्यरत असल्याचे सिद्ध करता येते.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      type: file
      path: /var/backups/litestream/app

Field replica हे singular आहे, हे लक्षात ठेवा. Litestream 0.5 मध्ये 0.3 series मधील replicas array ऐवजी single replica block वापरला जातो. आता दोन entries असलेली configuration startup वेळी fail होते. अनेक third-party guides मध्ये अजूनही जुना array दाखवला जातो. त्यामुळे search मध्ये प्रथम सापडणारे example वापरण्याऐवजी वरील रचना copy करा. 0.5 series मध्ये litestream wal subcommand चे नाव बदलून litestream ltx केले आहे, कारण on-disk backup format बदलला आहे.

काहीही enable करण्यापूर्वी configuration parse होते का ते तपासा.

sudo litestream databases -config /etc/litestream.yml

त्यानंतर round trip हाताने तपासा. या पद्धतीत configuration file वगळली जाते आणि एक database एका path वर replicate केला जातो.

mkdir -p /tmp/replica
litestream replicate ~/app/app.db file:///tmp/replica/app

हा command foreground मध्ये चालतो आणि सुरूच राहतो. दुसऱ्या shell मध्ये एक row लिहा आणि replica नवीन file मध्ये restore करा.

sqlite3 ~/app/app.db "INSERT INTO notes (body) VALUES ('written after replication started');"
litestream restore -o /tmp/restored.db file:///tmp/replica/app
sqlite3 /tmp/restored.db "SELECT count(*) FROM notes;"

या count मध्ये नवीन row समाविष्ट आहे. तो समाविष्ट नसेल, तर बदल अद्याप sync झालेला नाही. Litestream sync-interval वर push करते, ज्याचे default मूल्य 1 second आहे. त्यामुळे थांबा आणि पुन्हा restore करा. हा एक second तुमचा recovery point देखील आहे. Crash झाल्यास शेवटच्या sync interval मधील writes पैकी जास्तीत जास्त तेवढे writes गमावले जाऊ शकतात. कोणतीही configuration हे शून्यावर आणू शकत नाही.

प्रत्यक्ष storage साठी replica block ऐवजी S3 URL वापरा. हे Amazon S3 तसेच इतर providers च्या S3-compatible object storage सोबत कार्य करते.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      url: s3://your-bucket-name/app
      region: us-east-1

snapshot:
  interval: 24h
  retention: 24h

Credentials त्या file मध्ये ठेवू नका. Litestream environment मधून LITESTREAM_ACCESS_KEY_ID आणि LITESTREAM_SECRET_ACCESS_KEY वाचते. त्यामुळे ती root च्या मालकीच्या mode 600 असलेल्या systemd drop-in मध्ये ठेवा.

वरील snapshot values ही defaults आहेत. Retention चे default मूल्य अनेकांना अनपेक्षित वाटते. Retention म्हणजे Litestream snapshots आणि त्यांच्याशी संबंधित files किती काळ ठेवते तो कालावधी. त्यामुळे भूतकाळातील किती दूरच्या वेळेपर्यंत restore करता येईल हेही त्यावर ठरते. Twenty-four hours म्हणजे Wednesday morning ला लक्षात आलेले चुकीचे migration Monday च्या state मधून restore करता येणार नाही. retention: 168h एक week साठी सेट करा आणि अतिरिक्त storage साठी लागणारा खर्च स्वीकारा.

आवश्यकता भासण्यापूर्वी पुनर्संचयितीकरणाची चाचणी घ्या

litestream restore -o /tmp/check.db /home/appuser/app/app.db
sqlite3 /tmp/check.db "PRAGMA integrity_check;"
sqlite3 /tmp/check.db "SELECT count(*) FROM notes;"

डेटाबेसचा path दिल्यावर litestream restore, /etc/litestream.yml मध्ये जुळणारी replica शोधते आणि ती डाउनलोड करते. निरोगी file असल्यास PRAGMA integrity_check, ok प्रदर्शित करते. इतर कोणतेही output म्हणजे पुनर्संचयित केलेली copy वापरण्यायोग्य नाही. हे काम systemd service आणि timer वापरून ठरावीक वेळापत्रकानुसार चालवा आणि output वाचा. Backup एकदा पुनर्संचयित करेपर्यंत ते कार्यरत आहे याची खात्री होत नाही.

systemd अंतर्गत Litestream चालवा

Debian पॅकेज litestream unit स्थापित करते. हे unit /etc/litestream.yml वाचते.

sudo systemctl enable litestream
sudo systemctl start litestream
sudo journalctl -u litestream -f

यशस्वी output मध्ये configuration मधील प्रत्येक database चे नाव दिसते. त्यानंतर periodic sync lines वगळता output शांत राहतो. तुमच्या database path वर no such file or directory अशी त्रुटी आल्यास configuration मधील path चुकीचा आहे किंवा process तो path वाचू शकत नाही. हे unit default म्हणून root वापरते. या कामासाठी त्याला आवश्यकतेपेक्षा जास्त privileges मिळतात. Litestream ला database आणि तो असलेली directory या दोन्ही ठिकाणी read आणि write करण्याची परवानगी असणे आवश्यक आहे. कारण ते database जवळील -wal आणि -shm files सह कार्य करते. त्यामुळे तुमचा application आधीपासून वापरत असलेला account द्या.

# /etc/systemd/system/litestream.service.d/override.conf
[Service]
User=appuser
Group=appuser

sudo systemctl daemon-reload आणि sudo systemctl restart litestream वापरून ते लागू करा. किमान privileges असलेले स्वतंत्र service account तयार करणे यासाठी काही मिनिटे लागतात. यामुळे backup agent आणि त्या मशीनवरील दुसरी root process यांमधील फरक ठरतो.

मशीन पूर्णपणे नव्याने उभारायची असल्यास एक execution order महत्त्वाचा ठरतो. Application सुरू होण्यापूर्वी database restore झालेले असावे. litestream restore मध्ये -if-db-not-exists स्वीकारले जाते. File आधीपासून अस्तित्वात असल्यास ते 0 ने exit होते. त्यामुळे ते प्रत्येक boot वेळी सुरक्षितपणे चालवता येते. तुमच्या application च्या unit मधील ExecStartPre line मध्ये ते ठेवा. त्यानंतर नवीन VPS database download करेल, तर आधीपासून अस्तित्वात असलेल्या VPS वर काहीही केले जाणार नाही. ते एकाच ठिकाणी ठेवायचे असल्यास litestream replicate मध्ये त्यास अनुरूप -restore-if-db-not-exists flag उपलब्ध आहे.

VPS वर SQLite कुठे अपयशी ठरते

Network filesystems. ही अशी मर्यादा आहे जिच्याभोवती configuration करून मार्ग काढता येत नाही. WAL mode साठी database वापरणाऱ्या प्रत्येक process ने memory चा एक छोटा भाग share करणे आवश्यक असते. हा भाग -shm file पुरवते. SQLite documentation मध्ये हा नियम कोणतीही अट न लावता स्पष्ट केला आहे:

Database वापरणारे सर्व processes एकाच host computer वर असले पाहिजेत; network filesystem वर WAL कार्य करत नाही.

म्हणून mounted NFS (network file system) किंवा SMB share वर असलेला database corrupt होऊ शकतो. कोणताही pragma हे प्रतिबंधित करू शकत नाही. येथे एक महत्त्वाचा फरक आहे, जो अनेकदा लक्षात घेतला जात नाही. बहुतेक VPS providers अतिरिक्त storage म्हणून जोडतात ते network block device असते. Linux ला ते त्यावरील सामान्य filesystem असलेल्या सामान्य disk प्रमाणे दिसते आणि ते योग्य आहे. Mounted file share मात्र वेगळे असते.

A second application server. कोणतीही setting हे कार्यरत करू शकत नाही. एकच data दोन machines वरून serve करण्याची गरज पडताच network वरून संवाद साधणारा database आवश्यक असतो. नियोजनासाठी वेळ उपलब्ध असतानाच हा बदल करायचा की नाही ते ठरवा.

Write-heavy workloads. एका वेळी एकच writer असणे हे file format चे वैशिष्ट्य आहे; ते tunable नाही. प्रत्येक commit हा WAL मध्ये append असल्यामुळे short writes स्वस्त असतात. त्यामुळे throughput तुमच्या CPU पेक्षा disk च्या small-write latency वर अधिक अवलंबून असतो. या फरकाचे स्वरूप VPS वरील NVMe आणि SATA SSD storage येथे पाहा. Long transactions ही खरी अडचण आहे, कारण त्या त्यांच्या मागे इतर प्रत्येक writer ला रांगेत थांबवतात.

Analytical queries. SQLite हा transactions साठी तयार केलेला row store आहे. शंभर million rows scan करणारा dashboard हा वेगळ्या tool साठी योग्य वेगळा प्रकारचा कार्यभार आहे. ही सीमा कुठे येते ते server कामासाठी DuckDB आणि SQLite ची तुलना येथे स्पष्ट केले आहे.

VACUUM under replication. पूर्ण VACUUM संपूर्ण database file पुन्हा लिहिते. त्यामुळे Litestream ला ती संपूर्ण file पुन्हा upload करावी लागते. Replication सक्रिय असताना हे in place चालवू नये, असा Litestream documentation मधील सल्ला आहे. Replicator थांबवा, vacuum चालवा, तो पुन्हा सुरू करा आणि नवीन full snapshot तयार होण्याची अपेक्षा ठेवा.

Two replicators on one database. एकाच database किंवा त्याच replica destination विरुद्ध दोन Litestream processes कधीही चालवू नका. हे रोखण्याची जबाबदारी तुमची आहे, असे documentation स्पष्टपणे सांगते. अन्यथा अशी replica तयार होऊ शकते जिचे restore करता येत नाही.

Litestream कशाचे संरक्षण करत नाही

Litestream फक्त database file चे संरक्षण करते. इतर कोणत्याही गोष्टीचे नाही. Uploaded files, application config, TLS (transport layer security) certificates आणि unit files यांचे व्यवस्थापन तुम्हालाच करावे लागते. ठरावीक वेळापत्रकानुसार restic वापरून encrypted off-box backups सोबत याचा वापर करा. त्यामुळे दोन्ही भागांचे संरक्षण होते. मशीन नवीन असल्यास, या मार्गदर्शकात आधीच पूर्ण झालेले गृहीत धरलेले user account आणि firewall चे काम नवीन VPS वरील पहिली दहा मिनिटे येथे दिले आहे.

FAQ

उत्पादन अनुप्रयोगासाठी SQLite पुरेसे आहे का?

एका सर्व्हरवरील एका अनुप्रयोगासाठी ते पुरेसे आहे, परंतु तुम्ही WAL mode सुरू केले पाहिजे, busy timeout सेट केला पाहिजे आणि त्याचा सातत्याने backup घेतला पाहिजे. महत्त्वाच्या मर्यादा संरचनात्मक आहेत: एका वेळी फक्त एक writer आणि फक्त एक host machine. या मर्यादांमध्ये बसणाऱ्या अनुप्रयोगाला network hop किंवा monitor करण्यासाठी स्वतंत्र process नसलेला database मिळतो. या मर्यादांमध्ये न बसणाऱ्या अनुप्रयोगाला client-server database आवश्यक असतो. कोणत्याही tuning मुळे ही वस्तुस्थिती बदलत नाही.

busy_timeout सेट केल्यानंतरही मला database is locked का मिळते?

कारण प्रतीक्षा केल्यामुळे deadlock होण्याची शक्यता असल्यास SQLite busy handler वगळतो. साध्या BEGIN ने सुरू होणारा transaction deferred असतो: सुरुवातीचे SELECT त्याला read transaction मध्ये ठेवते आणि नंतरच्या write साठी त्याचे upgrade करावे लागते. त्यादरम्यान दुसऱ्या connection ने write केले असल्यास SQLite तुमचा busy handler call न करता त्वरित SQLITE_BUSY परत करतो, कारण तुमचा read snapshot आधीच stale झालेला असतो. write करणारा कोणताही transaction BEGIN IMMEDIATE ने सुरू करा. त्यामुळे write lock सुरुवातीलाच घेतला जातो आणि timeout लागू होतो.

माझा SQLite database network storage वर ठेवू शकतो का?

NFS किंवा SMB सारख्या network filesystem वर ठेवू नका. WAL mode ला -shm file द्वारे सर्व processes ने memory share करणे आवश्यक असते. SQLite documentation नुसार database वापरणारे सर्व processes एकाच host computer वर असणे आवश्यक आहे. तुमच्या provider ने जोडलेले network block device वेगळे असते. Linux ला त्यावर सामान्य filesystem असलेली सामान्य disk दिसते आणि SQLite तेथे कार्य करते.

मी nightly backups आधीच चालवत असल्यास Litestream आवश्यक आहे का?

तुम्ही किती data गमावणे परवडवून घेऊ शकता यावर ते अवलंबून आहे. Nightly job मुळे जास्तीत जास्त चोवीस तासांचे writes गमावले जाऊ शकतात. Litestream साधारणपणे प्रत्येक सेकंदाला sync करते, त्यामुळे crash झाल्यास अंदाजे शेवटचा एक सेकंद गमावला जातो. cp वापरून database file copy करण्यापेक्षा ते अधिक सुरक्षित आहे, कारण त्यामुळे write सुरू असतानाचा database capture होऊ शकतो. Litestream फक्त database चे संरक्षण करते. त्यामुळे त्यासोबत general file backup देखील चालू ठेवा.