Home Assistant SQLite के साथ आता है, और यह एक सप्ताह के लिए ठीक है। फिर डैशबोर्ड ग्राफ़ लगने लगते हैं, इतिहास पैनल खोलने में दस सेकंड लगते हैं, और रिकॉर्डर डेटाबेस कुछ गीगाबाइट तक बढ़ जाता है क्योंकि आपके Zigbee सेंसर हर 30 सेकंड में लिखते हैं। रिकॉर्डर बैकएंड को स्विच करने से यह ठीक हो जाता है। हमने एक ही उदाहरण के खिलाफ छह डेटाबेस चलाए (लगभग 140 इकाइयां, 30 दिन की प्रतिधारण) यह देखने के लिए कि कौन सा वास्तव में स्मार्ट होम को फिर से तेज़ बना देता है।
यह समीक्षा उन लोगों के लिए है जिनकी Home Assistant स्थापना डिफ़ॉल्ट डेटाबेस से आगे निकल गई है। Docker या bare-metal, हम प्रत्येक बैकएंड द्वारा लाई गई trade-offs को कवर करते हैं, माइग्रेशन के दौरान क्या टूटता है, और यदि आप दीर्घकालिक Grafana डैशबोर्ड भी चाहते हैं तो कौन सा चुनें।
Home Assistant recorder बैकएंड में क्या देखें
कुछ चीजें कच्ची बेंचमार्क से अधिक महत्वपूर्ण हैं:
- एक बार DB 5 GB से अधिक हो जाने के बाद इतिहास और लॉगबुक पैनल पर विलंबता
- बैकएंड Home Assistant के लेखन पैटर्न को कितनी अच्छी तरह संभालता है (बहुत सारे छोटे insertions, कभी-कभी बड़ी queries)
- क्या आप इसे Grafana या Node-RED से सीधे query कर सकते हैं बिना रिकॉर्डर को ओवरलोड किए
- प्रतिधारण और downsampling नियंत्रण, क्योंकि पूर्ण resolution को हमेशा के लिए रखना बर्बादी है
- Backup story, खासकर यदि आप सब कुछ एक SSD पर चलाते हैं जिसे आप जीवित रखना चाहते हैं
- SQLite से माइग्रेशन पथ (क्या आप इतिहास रख सकते हैं?)
त्वरित तुलना
| Backend | के लिए सर्वश्रेष्ठ | लाइसेंस | Storage मॉडल | चलता है |
|---|---|---|---|---|
| PostgreSQL | अधिकांश installations | PostgreSQL | Row-store, ACID | Linux, Windows, macOS |
| MariaDB | Drop-in replacement | GPL | Row-store, ACID | Linux, Windows, macOS |
| TimescaleDB | दीर्घकालीन सेंसर इतिहास | Apache 2.0 / TSL | Postgres पर Hypertables | Linux, Docker |
| InfluxDB 2.x | डैशबोर्ड, downsampling | MIT (core) | Time-series columnar | Linux, Windows, macOS |
| MySQL | मौजूदा MySQL infrastructure | GPL | Row-store, ACID | Linux, Windows, macOS |
| VictoriaMetrics | पैमाने पर metrics | Apache 2.0 | Time-series columnar | Linux, Windows, macOS |
बैकएंड
1. PostgreSQL, सर्वश्रेष्ठ समग्र रिकॉर्डर प्रतिस्थापन
PostgreSQL वह है जिसे चुनें यदि आप निश्चित नहीं हैं। Home Assistant इसे natively support करता है, psycopg2 driver स्थिर है, और query planning डेटाबेस के 10 GB से अधिक बढ़ने पर भी काम करती है। इतिहास पैनल जो SQLite पर आठ सेकंड लगता था एक skromn चार-core box पर एक सेकंड से कम हो जाता है एक बार indexes गर्म हो जाते हैं। states और events टेबल पर TOAST compression जोड़ें और disk usage उचित रहता है।
कहां यह विफल होता है: आपको एक real database चलाना और backup करना होगा। इसका मतलब pg_dump cron, WAL archive यदि आप point-in-time recovery की परवाह करते हैं, और एक योजना जब disk भर जाए। कुछ भी exotic नहीं, लेकिन यह एक single .db file से अधिक काम है।
मूल्य: निःशुल्क, PostgreSQL license के तहत open-source। कोई paid tier नहीं।
Platforms: Linux, Windows, macOS, Docker, और Postgres package वाला कोई भी NAS।
डाउनलोड: postgresql.org
निष्कर्ष: पहले PostgreSQL चुनें, और केवल अन्यत्र देखें यदि आपके पास कोई specific reason हो।
2. MariaDB, वह fork जिसे अधिकांश guides मान लेते हैं
MariaDB वह backend है जिसे Home Assistant का documentation अपने उदाहरण में use करता है, और यह उन सभी के लिए एक solid choice बना हुआ है जो पहले से इसे चला रहे हैं। Setup को exact recorder: YAML block तक दस्तावेज़ दिया गया है, और Home Assistant OS में एक MariaDB add-on है जो आपके लिए install को handle करता है। Performance recorder workload के लिए Postgres के समान है।
कहां यह विफल होता है: heavy write load के तहत schema migrations कभी-कभी states table को काफी लंबे समय के लिए lock करते हैं कि recorder backpressure warnings log करे। कुछ भी catastrophic नहीं, लेकिन आप इसे देखते हैं। MySQL-flavored tooling भी Postgres ecosystem से ज़्यादा पुराना महसूस होता है।
मूल्य: निःशुल्क, GPLv2 के तहत open-source।
Platforms: Linux, Windows, macOS, Docker, native HAOS add-on।
डाउनलोड: mariadb.org
निष्कर्ष: सबसे सुरक्षित पसंद यदि आप एक supported, documented path चाहते हैं जिसमें सबसे कम surprises हों।
3. TimescaleDB, Postgres सेंसर इतिहास के लिए tuned
TimescaleDB PostgreSQL extension के रूप में चलता है और time-series tables को hypertables में बदल देता है जो समय के अनुसार automatically partitioned होते हैं। एक स्मार्ट home के लिए जो daily हजारों state changes log करता है, इसका मतलब है कि आप एक साल का data रख सकते हैं और अभी भी sub-second range queries पा सकते हैं। Continuous aggregates आपको daily averages को pre-compute करने देता है ताकि Grafana panels raw rows को scan न करें।
कहां यह विफल होता है: आपको Home Assistant के recorder को normally Postgres के through route करना होगा, फिर tables को manual SQL command के साथ hypertables में convert करना होगा। मुश्किल नहीं, लेकिन एक checkbox नहीं। कुछ enterprise features पर Timescale License (TSL) पूरी तरह open source नहीं है, लेकिन community edition सब कुछ cover करता है जो recorder को चाहिए।
मूल्य: निःशुल्क community edition; paid Timescale Cloud लगभग $30/month से hosted instances के लिए शुरू होता है।
Platforms: Linux, Docker, Timescale Cloud. कोई native Windows या macOS packages नहीं, हालांकि WSL काम करता है।
डाउनलोड: timescale.com
निष्कर्ष: छः में से सर्वश्रेष्ठ long-term retention story, यदि आप Postgres के top पर एक extension चलाने के लिए सहज हैं।
4. InfluxDB 2.x, recorder से अधिक dashboards
InfluxDB really एक recorder replacement नहीं है, यह classic pairing है जो Home Assistant के बगल में रहता है। influxdb integration state changes को InfluxDB में stream करता है parallel में whatever SQL backend के साथ recorder use कर रहा है, और Grafana pretty dashboards के लिए Influx से pull करता है। Flux queries आपको cronjobs के बिना downsample करने देते हैं।
कहां यह विफल होता है: Influx query language 1.x, 2.x, और 3.x के बीच बदल गई, इसलिए आप जो tutorials पाते हैं उनमें से आधा outdated है। और क्योंकि यह recorder को replace नहीं करता, आप एक के बजाय दो databases चला रहे हैं।
मूल्य: निःशुल्क open-source InfluxDB 2.x OSS; InfluxDB Cloud के पास एक free tier है और इसके above pay-as-you-go pricing है।
Platforms: Linux, Windows, macOS, Docker, HAOS add-on।
डाउनलोड: influxdata.com
निष्कर्ष: इसे एक SQL recorder के साथ use करें जब आप serious Grafana dashboards चाहते हैं, recorder replacement के रूप में नहीं।
5. MySQL, केवल यदि आप इसे पहले से चला रहे हैं
MySQL Home Assistant के साथ काम करता है, और यदि आपके पास पहले से एक MySQL server किसी अन्य service के लिए चल रहा है, तो इसमें एक recorder database जोड़ना straightforward है। mysqlclient driver well-worn है, और recorder इसे कठोर नहीं लगाता।
कहां यह विफल होता है: MariaDB एक drop-in fork है जिसे अधिकांश Home Assistant guides directly target करते हैं, इसलिए आप instructions का अनुवाद करते हैं। MySQL Enterprise के around Oracle की licensing एक wrinkle जोड़ता है यदि आप कभी paid support चाहते थे।
मूल्य: निःशुल्क MySQL Community Edition; paid Enterprise tiers लगभग $2,000/year से शुरू होते हैं।
Platforms: Linux, Windows, macOS, Docker.
डाउनलोड: mysql.com
निष्कर्ष: केवल यदि आपके पास पहले से एक MySQL instance है जिसे आप reuse करना चाहते हैं तो चुनें।
6. VictoriaMetrics, जब recorder bottleneck हो
VictoriaMetrics चमकता है जब आपके पास सैकड़ों entities हैं और recorder itself slow part बन जाता है। यह Prometheus-compatible endpoint के through ingest करता है, इसलिए Home Assistant prometheus integration इसे directly feed करता है। Storage InfluxDB के मुकाबले same data के लिए लगभग 10x ज़्यादा compact है।
कहां यह विफल होता है: यह metrics-only है। आपको state history उसी तरह नहीं मिलता जैसे recorder देता है, इसलिए built-in history panel को अभी भी एक SQL backend की जरूरत है। यह एक supplement है, replacement नहीं।
मूल्य: निःशुल्क open-source; बड़ी deployments के लिए VictoriaMetrics Enterprise में custom pricing है।
Platforms: Linux, Windows, macOS, Docker.
डाउनलोड: victoriametrics.com
निष्कर्ष: जब आपके Prometheus exports chunky बन जाएं और Influx भारी लगने लगे तो reach करने के लिए metrics store।
सही चुनें कैसे करें
यदि आप बस चाहते हैं कि आपका dashboard तेज़ महसूस हो: PostgreSQL, और यहां पढ़ना बंद करें।
यदि आप guides को closely follow करते हैं और documented path चाहते हैं: MariaDB.
यदि आप years का sensor history रखने की योजना बनाते हैं और बाद में इसे query करना चाहते हैं: PostgreSQL पर TimescaleDB।
यदि आपका लक्ष्य really nice Grafana dashboards है downsampling के साथ: recorder को Postgres या MariaDB पर रखें, और metrics layer के लिए InfluxDB जोड़ें।
यदि आपकी Home Assistant installation genuinely huge है (500+ entities, million+ state changes प्रति दिन): PostgreSQL को recorder के रूप में VictoriaMetrics के साथ Prometheus-style metrics के लिए pair करें।
MySQL को skip करें जब तक आप इसे पहले से कुछ और के लिए चला नहीं रहे हों।
सामान्य प्रश्न
क्या PostgreSQL Home Assistant के लिए SQLite से तेज़ है?
हां, एक बार आपका database कुछ gigabytes से अधिक हो जाता है। छोटी installations पर SQLite comparable है, लेकिन history और logbook panels data के बढ़ने के साथ PostgreSQL पर noticeably तेज़ हैं, क्योंकि query planning और concurrent reads बेहतर scale करते हैं।
क्या मैं अपना SQLite history को PostgreSQL में बिना data खोए migrate कर सकता हूं?
हां, pgloader या manual dump/restore का उपयोग करके, लेकिन यह messy है। अधिकांश users नई backend के साथ fresh शुरू करते हैं और schema conversion से लड़ने के बजाय पुराने history के नुकसान को स्वीकार करते हैं।
क्या Home Assistant InfluxDB को recorder replacement के रूप में support करता है?
नहीं। InfluxDB influxdb integration के through recorder के साथ काम करता है, parallel में state changes को stream करते हुए। Recorder को स्वयं को अभी भी SQLite, PostgreSQL, MariaDB, या MySQL की आवश्यकता है।
Home Assistant के लिए long-term history के लिए सर्वश्रेष्ठ backend कौन सा है?
TimescaleDB. Continuous aggregates और time-based partitioning आपको एक साल या अधिक का data रखने और अभी भी fast queries पाने देते हैं। VictoriaMetrics करीब है यदि आप केवल numeric metrics की परवाह करते हैं।
क्या recorder backend को बदलना मेरे automations को break करेगा?
नहीं। Automations Home Assistant के state machine से read करते हैं, recorder database से नहीं। Backend को swap करने से history, statistics, और long-term retention प्रभावित होता है, live state नहीं।