<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Case Studies on KvSQL.com</title>
    <link>https://kvsql.com/tags/case-studies/</link>
    <description>Recent content in Case Studies on KvSQL.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 22 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://kvsql.com/tags/case-studies/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Case Study: A Checkout That Is Never Half Done, Tested With 1200 Power Cuts</title>
      <link>https://kvsql.com/case-study-a-checkout-that-is-never-half-done-tested-with-1200-power-cuts/</link>
      <pubDate>Thu, 22 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://kvsql.com/case-study-a-checkout-that-is-never-half-done-tested-with-1200-power-cuts/</guid>
      <description>&lt;p&gt;A checkout touches several things that must change together. The cart goes away, an order appears with its lines, and the stock goes down. If the power fails halfway, the worst outcomes are an order with the stock never taken, or a paid order with the cart still sitting there. With a key-value store for carts and an SQL database for orders, those are two systems and two commits, and somebody has to write the cleanup for the gap between them.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Case Study: An Edge Gateway Collecting Sensor Readings Over HTTP With kvsqld</title>
      <link>https://kvsql.com/case-study-an-edge-gateway-collecting-sensor-readings-over-http-with-kvsqld/</link>
      <pubDate>Thu, 22 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://kvsql.com/case-study-an-edge-gateway-collecting-sensor-readings-over-http-with-kvsqld/</guid>
      <description>&lt;p&gt;An edge gateway sits between a set of devices and the rest of the world. Sensors post readings to it, a dashboard on the same network shows the latest value per device, and someone asks about history: averages, peaks, the hour a fridge ran warm. The gateway is often a small box with no room for a database team, so it should be one program and one file.&lt;/p&gt;&#xA;&lt;p&gt;This case study runs that set-up with &lt;code&gt;kvsqld&lt;/code&gt;. Twenty simulated devices post readings over HTTP on their own connections, while a dashboard reads the latest value by key and asks SQL for history. It&amp;rsquo;s part of &lt;a href=&#34;https://github.com/softdevstudio/kvsql/blob/main/crates/kvsql-db/examples/case_studies.rs&#34;&gt;case_studies.rs&lt;/a&gt; in the repository. The figures are from its recorded run of October 22, 2026, on a real file on a Linux container with two virtual CPUs. The output is in &lt;a href=&#34;https://github.com/softdevstudio/kvsql/blob/main/test/results/latest/case-studies.md&#34;&gt;case-studies.md&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Case Study: Sessions and Reporting in One Store Instead of Two</title>
      <link>https://kvsql.com/case-study-sessions-and-reporting-in-one-store-instead-of-two/</link>
      <pubDate>Thu, 22 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://kvsql.com/case-study-sessions-and-reporting-in-one-store-instead-of-two/</guid>
      <description>&lt;p&gt;A web application checks its session table on every request. A token comes in, and the app needs the user behind it, fast. Once in a while somebody wants a different view of the same data: how many sessions are live per country, or every session of one user, revoked at once when a password changes. Teams often split this in two, with sessions in Redis for speed and a copy in SQL for the reports and the bulk revokes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
