<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>wenc</author><text>That&amp;#x27;s a good pattern for straight data retrieval.&lt;p&gt;Unfortunately if you need to do aggregated queries on all of the SQLLite tables, things may be challenging.&lt;p&gt;But if you could somehow connect Spark to a folder (on a distributed FS) of these SQLite files...&lt;p&gt;Edit: Also SQLite has a limitation that only one process can write to it at a given a time. For this particular use case though, it shouldn&amp;#x27;t be a problem unless you have rewrites coming from various sources (which can happen when correcting data)</text><parent_chain><item><author>lbruder</author><text>We use a combination of SQLite and a sharding frontend service. One SQLite database file per device, one table per sensor, table contents are timestamp and measured value. As simple as it gets, easy to scale, and damn fast.&lt;p&gt;But try telling people you&amp;#x27;re using SQLite to store critical data...</text></item><item><author>kodablah</author><text>Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered&amp;#x2F;hidden) and Riak (admittedly haven&amp;#x27;t kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech company. Sorry TimescaleDB, I see you have raised a decent amount of funding, but I have to choose my DBs w&amp;#x2F; trepidation these days.&lt;p&gt;0 - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.theregister.co.uk&amp;#x2F;2017&amp;#x2F;07&amp;#x2F;13&amp;#x2F;will_the_last_person_at_basho_get_the_lights_oh_too_late&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.theregister.co.uk&amp;#x2F;2017&amp;#x2F;07&amp;#x2F;13&amp;#x2F;will_the_last_perso...&lt;/a&gt;</text></item></parent_chain></comment><story><title>It’s About Time for Time Series Databases</title><url>https://www.nextplatform.com/2018/01/25/time-time-series-databases/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>baldfat</author><text>&amp;gt; But try telling people you&amp;#x27;re using SQLite to store critical data...&lt;p&gt;SQLite is solid and trusted by many but for some unknown reason some people refuse to see it as a solution for their needs. I have seen many databases that could easily been replaced by SQLite.</text><parent_chain><item><author>lbruder</author><text>We use a combination of SQLite and a sharding frontend service. One SQLite database file per device, one table per sensor, table contents are timestamp and measured value. As simple as it gets, easy to scale, and damn fast.&lt;p&gt;But try telling people you&amp;#x27;re using SQLite to store critical data...</text></item><item><author>kodablah</author><text>Sorry to leave the technical detail part real quick. But is anyone else concerned about using a DB solely from a company built specifically around that DB? After Rethink DB (sustainability issue) and Foundation DB (bought and shuttered&amp;#x2F;hidden) and Riak (admittedly haven&amp;#x27;t kept up but I saw [0]), I am wary of using any DB that is not built by a large community or is not built as a non-core project from a large tech company. Sorry TimescaleDB, I see you have raised a decent amount of funding, but I have to choose my DBs w&amp;#x2F; trepidation these days.&lt;p&gt;0 - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.theregister.co.uk&amp;#x2F;2017&amp;#x2F;07&amp;#x2F;13&amp;#x2F;will_the_last_person_at_basho_get_the_lights_oh_too_late&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.theregister.co.uk&amp;#x2F;2017&amp;#x2F;07&amp;#x2F;13&amp;#x2F;will_the_last_perso...&lt;/a&gt;</text></item></parent_chain></comment><story><title>It’s About Time for Time Series Databases</title><url>https://www.nextplatform.com/2018/01/25/time-time-series-databases/</url></story>