<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Couchbase on Lorbic</title><link>http://localhost:1313/tags/couchbase/</link><description>Recent content in Couchbase on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 31 Jul 2026 23:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/couchbase/index.xml" rel="self" type="application/rss+xml"/><item><title>Couchbase Index Best Practices and Query Performance Tuning</title><link>http://localhost:1313/couchbase-index-best-practices-performance-tuning/</link><pubDate>Fri, 31 Jul 2026 23:00:00 +0530</pubDate><guid>http://localhost:1313/couchbase-index-best-practices-performance-tuning/</guid><description>&lt;p>Most Couchbase performance tickets I have seen end the same way: someone adds more nodes, the dashboard looks a little better for a week, and the same query shows up in the slow log a month later. The node count was never the problem. The index was.&lt;/p>
&lt;p>This is a working reference, not an essay. I already wrote &lt;a href="http://localhost:1313/what-couchbase-taught-me-about-system-thinking/">the reflective version&lt;/a> of what indexing in Couchbase teaches you about systems in general. This post skips the reflection and gets straight to the decisions: which index type to reach for, how to order composite keys, how to tell if a query is actually using what you built, and which four or five mistakes account for most of the slow queries you will ever debug. Couchbase&amp;rsquo;s own documentation is the primary source for the recommendations below. Every example runs against &lt;code>travel-sample&lt;/code>, the sample bucket Couchbase ships with every install, so you can paste these into your own cluster and see the plan yourself.&lt;/p></description></item><item><title>OLTP vs OLAP - Why You Need Two Databases</title><link>http://localhost:1313/oltp-vs-olap-why-you-need-two-databases/</link><pubDate>Sun, 11 Jan 2026 21:00:00 +0530</pubDate><guid>http://localhost:1313/oltp-vs-olap-why-you-need-two-databases/</guid><description>&lt;p>At a recent ClickHouse conference in New Delhi, I attended this Saturday. There were many interesting sessions, but one that stood out was a talk on multi-tenant analytics at scale. I was reminded of a fundamental truth in backend engineering: &amp;ldquo;The database that runs your app cannot be the database that analyzes your app&amp;rdquo;.&lt;/p>
&lt;p>Early in a startup&amp;rsquo;s life, we shove everything into one database. User profiles, session data, logs, and analytics events all live in the same Postgres, Mongo, or Couchbase instance. It works, until it throttles.&lt;/p></description></item><item><title>Introducing CouchLens: A Query Analysis Tool for Couchbase</title><link>http://localhost:1313/couchlens-couchbase-query-analysis-tool/</link><pubDate>Sun, 28 Dec 2025 20:00:00 +0530</pubDate><guid>http://localhost:1313/couchlens-couchbase-query-analysis-tool/</guid><description>&lt;p>CouchLens is a client-side web application for analyzing Couchbase N1QL query performance. You feed it JSON exports from &lt;code>system:completed_requests&lt;/code>, &lt;code>system:indexes&lt;/code>, and schema inference results. It parses execution plans, computes metrics, detects inefficiencies, and generates a report showing where your queries are slow.&lt;/p>
&lt;p>Everything runs in the browser. No data leaves your machine. The tool is a Progressive Web App, so you can install it and use it offline. The goal is to give database administrators and developers a way to understand query behavior without writing custom scripts or debugging raw JSON.&lt;/p></description></item><item><title>What Couchbase Taught Me About System Thinking</title><link>http://localhost:1313/what-couchbase-taught-me-about-system-thinking/</link><pubDate>Tue, 18 Nov 2025 02:20:06 +0530</pubDate><guid>http://localhost:1313/what-couchbase-taught-me-about-system-thinking/</guid><description>&lt;h2 id="couchbase-internals-indexes-queries-consistency-and-performance">Couchbase Internals: Indexes, Queries, Consistency, and Performance&lt;a class="anchorjs-link" href="#couchbase-internals-indexes-queries-consistency-and-performance" aria-label="Link to section: Couchbase Internals: Indexes, Queries, Consistency, and Performance">&lt;/a>&lt;/h2>&lt;h3 id="introduction">Introduction&lt;a class="anchorjs-link" href="#introduction" aria-label="Link to section: Introduction">&lt;/a>&lt;/h3>&lt;p>Over the last few years I&amp;rsquo;ve lived deep inside backend systems, and for the past year and a half Couchbase has been my daily companion. Working with Go services that depend on Couchbase taught me that the real lessons aren&amp;rsquo;t in the marketing slides or quick‑start guides. They&amp;rsquo;re in the internals: how indexes are built, how queries are planned, how consistency flags change the story, and how durability levels quietly decide whether your system survives a failure or not.&lt;/p></description></item><item><title>Bitmasking In Go</title><link>http://localhost:1313/bitmasking/</link><pubDate>Thu, 17 Apr 2025 02:20:00 +0000</pubDate><guid>http://localhost:1313/bitmasking/</guid><description>&lt;h1 id="bitmasking-in-go">Bitmasking in Go&lt;a class="anchorjs-link" href="#bitmasking-in-go" aria-label="Link to section: Bitmasking in Go">&lt;/a>&lt;/h1>&lt;p>Bitmasking is one of those computer science tricks that feels like wizardry, until you realize it&amp;rsquo;s just some clever shifting and binary math. This blog explores the idea, shows how we use it in Go, and why it&amp;rsquo;s surprisingly useful when working with databases like Couchbase.&lt;/p>
&lt;hr>
&lt;h2 id="whats-bitmasking">What&amp;rsquo;s Bitmasking?&lt;a class="anchorjs-link" href="#whats-bitmasking" aria-label="Link to section: What&amp;rsquo;s Bitmasking?">&lt;/a>&lt;/h2>&lt;p>A &lt;strong>bitmask&lt;/strong> is just an integer where each &lt;strong>bit&lt;/strong> (0 or 1) represents a flag or state. Instead of storing multiple booleans in a slice or map, you cram them into a single &lt;code>int&lt;/code>. Fast to compute, fast to store, and great for indexing.&lt;/p></description></item></channel></rss>