<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Sqlite on ukue.com</title>
    <link>https://ukue.com/tags/sqlite/</link>
    <description>Recent content in Sqlite on ukue.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 06 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ukue.com/tags/sqlite/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Job Queue in One SQLite File: ukue 0.1 Lets Small Teams Skip Redis</title>
      <link>https://ukue.com/a-job-queue-in-one-sqlite-file-ukue-0.1-lets-small-teams-skip-redis/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/a-job-queue-in-one-sqlite-file-ukue-0.1-lets-small-teams-skip-redis/</guid>
      <description>&lt;p&gt;Sooner or later every web app needs to do something outside the request. Send the welcome email after the user has seen the page. Resize the photo while they carry on. Retry the webhook when the other side is down. The standard way to do that is a job queue, and the standard way to get a job queue is to run Redis or RabbitMQ next to your app.&lt;/p&gt;&#xA;&lt;p&gt;ukue 0.1 puts the whole queue in one file instead. It&amp;rsquo;s a SQLite database with a documented layout, and it holds every queue, every waiting job, every retry and every job that failed for good. A Go program imports ukue as a library. Everything else uses the one small &lt;code&gt;ukue&lt;/code&gt; binary, which runs a script for each job or serves a small HTTP API.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
