<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>KirinDave</author><text>&amp;gt; Is there actually a legitimate performance or scalability need to incorporate a NoSQL database in this case?&lt;p&gt;Usually the most compelling reason not to use a traditional SQL database is that they&amp;#x27;re expensive to field in distributed environments and require specialist engineers to support when you get out into the weeds.&lt;p&gt;But I submit it&amp;#x27;s a category error to call Redis a &amp;quot;NoSQL database.&amp;quot; It was also a category error to put data that needs to be redundant and durable into a storage system that is really specialized for high volume but low-reliability cache work.&lt;p&gt;I mean, seriously. Minimum viable PostgresSQL deploy in EC2 is pretty damn expensive, but you may not have enough cash on hand to buy your own hardware and pay to put it in a &amp;quot;real datacenter.&amp;quot; If you can find something cheaper and you&amp;#x27;re not even seed funded yet because no one funds your social product until you have 100k users, you&amp;#x27;re probably more likely to actually make it to where you can afford a different database by just using Redis. It&amp;#x27;s called &amp;quot;technical debt&amp;quot; and we accrue it both bitterly and often willingly.</text><parent_chain><item><author>PommeDeTerre</author><text>Is there actually a legitimate performance or scalability need to incorporate a NoSQL database in this case?&lt;p&gt;Ever since NoSQL databases started receiving a lot of hype a few years back, I&amp;#x27;ve witnessed a number of teams use them without any real justification. They&amp;#x27;ll build unnecessarily complex systems using one or more NoSQL database systems, all while a relational database would be more than sufficient for their needs.&lt;p&gt;In several of these cases, some of the developers have been quite adamant that these NoSQL databases are essential. Then we rip them out, usually because they&amp;#x27;ve been causing problems like described in this case. It quickly becomes obvious that they were never needed in the first place, and won&amp;#x27;t be needed even in the face of significantly increased load.</text></item><item><author>RobSpectre</author><text>Totally agree.  Need to clear up a developing misconception - Redis does not serve as the primary store for the account balance of Twilio&amp;#x27;s customers.   The billing system uses a double bookkeeping model common to many high volume designs with Redis as the in-flight data store (e.g. when a call or SMS message is created) with the transaction also stored independently to an RDBMS post-flight (e.g. when a call or SMS message is completed).&lt;p&gt;Clearly however our implementation failed dangerously and did not recover in a manner that meets our customers&amp;#x27; expectations.  Totally get how such a misconception would occur from a cursory read of the incident report - just need to be clear.</text></item><item><author>eblume</author><text>It&amp;#x27;s good to see Twilio post this! That being said - yeah, I really am concerned that Twilio is using an ephemeral database to store such important data. Why not simply use Postgres? Is Twilio really making so many transactions per second that Postgres won&amp;#x27;t scale?</text></item></parent_chain></comment><story><title>Twilio incident and Redis</title><url>http://antirez.com/news/60</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>AYBABTME</author><text>Some problems are better solved with key-value stores than with relational databases.  It depends on the data model you need to map.&lt;p&gt;Lot of people use relational databases as a big key value store, when really they should use a key value store.  It&amp;#x27;s not necessarily about scalability or performance. =)</text><parent_chain><item><author>PommeDeTerre</author><text>Is there actually a legitimate performance or scalability need to incorporate a NoSQL database in this case?&lt;p&gt;Ever since NoSQL databases started receiving a lot of hype a few years back, I&amp;#x27;ve witnessed a number of teams use them without any real justification. They&amp;#x27;ll build unnecessarily complex systems using one or more NoSQL database systems, all while a relational database would be more than sufficient for their needs.&lt;p&gt;In several of these cases, some of the developers have been quite adamant that these NoSQL databases are essential. Then we rip them out, usually because they&amp;#x27;ve been causing problems like described in this case. It quickly becomes obvious that they were never needed in the first place, and won&amp;#x27;t be needed even in the face of significantly increased load.</text></item><item><author>RobSpectre</author><text>Totally agree.  Need to clear up a developing misconception - Redis does not serve as the primary store for the account balance of Twilio&amp;#x27;s customers.   The billing system uses a double bookkeeping model common to many high volume designs with Redis as the in-flight data store (e.g. when a call or SMS message is created) with the transaction also stored independently to an RDBMS post-flight (e.g. when a call or SMS message is completed).&lt;p&gt;Clearly however our implementation failed dangerously and did not recover in a manner that meets our customers&amp;#x27; expectations.  Totally get how such a misconception would occur from a cursory read of the incident report - just need to be clear.</text></item><item><author>eblume</author><text>It&amp;#x27;s good to see Twilio post this! That being said - yeah, I really am concerned that Twilio is using an ephemeral database to store such important data. Why not simply use Postgres? Is Twilio really making so many transactions per second that Postgres won&amp;#x27;t scale?</text></item></parent_chain></comment><story><title>Twilio incident and Redis</title><url>http://antirez.com/news/60</url></story>