<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>OriginChainDB Engineering Blog</title><description>Engineering notes, design decisions, and customer stories from the team behind OriginChainDB - the AI-native database for SQL, vector, full-text, and graph.</description><link>https://originchaindb.com</link><language>en-us</language><atom:link href="https://originchaindb.com/api/blogs/rss.xml" rel="self" type="application/rss+xml"/><item><title>How a graph database works — and when it beats joins</title><link>https://originchaindb.com/blogs/how-graph-databases-work</link><guid isPermaLink="false">originchain-blog:how-graph-databases-work</guid><description>Relational databases store relationships as data you re-derive at query time with joins. Graph databases store them as structure you walk. That single difference decides which questions stay fast as data grows — and it&apos;s why fraud rings, recommendations, and agent memory are graph problems.</description><pubDate>Tue, 14 Jul 2026 09:00:00 GMT</pubDate><category>graph</category><category>cypher</category><category>database</category><category>engineering</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>How vector search actually works — from embeddings to HNSW</title><link>https://originchaindb.com/blogs/how-vector-search-works</link><guid isPermaLink="false">originchain-blog:how-vector-search-works</guid><description>Embeddings turn meaning into geometry; vector search turns geometry back into answers. A plain-language walk through similarity metrics, why brute force dies at scale, how HNSW graphs make approximate search fast, and what quantization actually trades away.</description><pubDate>Tue, 14 Jul 2026 08:00:00 GMT</pubDate><category>vector-search</category><category>embeddings</category><category>hnsw</category><category>engineering</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>The Token Economy Has Arrived — And Your AI Bill Is About to Meet Your CFO</title><link>https://originchaindb.com/blogs/token-economy-occi</link><guid isPermaLink="false">originchain-blog:token-economy-occi</guid><description>AI token usage has crossed from a technical detail to a strategic cost center — and &quot;token maxing&quot; is now one of the largest hidden line items at scale. OriginChainDB Contextual Intelligence (OCCI) cuts token consumption 30–50% while improving outcomes, by making context — not the model — the lever.</description><pubDate>Wed, 08 Jul 2026 09:00:00 GMT</pubDate><category>ai-costs</category><category>token-economy</category><category>occi</category><category>contextual-intelligence</category><category>enterprise</category><author>Zaheer (OriginChainDB)</author></item><item><title>The database is being redefined. Multi-modal is the new foundation.</title><link>https://originchaindb.com/blogs/multi-modal-is-the-new-foundation</link><guid isPermaLink="false">originchain-blog:multi-modal-is-the-new-foundation</guid><description>For decades a database had one job: exact answers to precise queries. The AI era needs more — semantic flexibility and deterministic precision, on one consistent copy of your data. Why we built OriginChainDB as a true multi-modal database.</description><pubDate>Wed, 01 Jul 2026 08:00:00 GMT</pubDate><category>multi-modal</category><category>ai</category><category>vector-search</category><category>agentic-ai</category><category>enterprise</category><author>Zaheer (OriginChainDB)</author></item><item><title>One database, every query shape: why we built OriginChainDB</title><link>https://originchaindb.com/blogs/one-database-every-query-shape</link><guid isPermaLink="false">originchain-blog:one-database-every-query-shape</guid><description>The modern AI stack is a database plus a vector DB plus a search index plus glue code. OriginChainDB is one managed store that answers SQL, vector, full-text, graph, and natural-language queries — the same write visible to every shape, atomically.</description><pubDate>Mon, 22 Jun 2026 08:00:00 GMT</pubDate><category>database</category><category>ai</category><category>vector-search</category><category>engineering</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>Multi-region cold standby for $5/month instead of $78/month</title><link>https://originchaindb.com/blogs/multi-region-cold-standby-5-vs-78-per-month</link><guid isPermaLink="false">originchain-blog:multi-region-cold-standby-5-vs-78-per-month</guid><description>We refactored our multi-region DR from a textbook hot-standby model to a cold-standby model and dropped per-tenant DR cost from ~$78/mo to ~$5–15/mo. RPO ≤60 s, RTO ~10–15 min. The math, the runbook excerpt, and the trade-off named explicitly.</description><pubDate>Sun, 07 Jun 2026 09:00:00 GMT</pubDate><category>dr</category><category>infrastructure</category><category>cost</category><category>engineering</category><category>operations</category><author>OriginChainDB engineering (OriginChainDB)</author></item><item><title>How we test our database with 850,000 random API probes a day</title><link>https://originchaindb.com/blogs/850000-random-api-probes-a-day</link><guid isPermaLink="false">originchain-blog:850000-random-api-probes-a-day</guid><description>A 24/7 fuzz canary fires ~10,000 random probes at our engine every minute, with a metric, a two-minute alarm, and assertions on no-5xx / JSON-parseable / 401-on-no-auth. 14 generator families, ~85% surface coverage, p99 ~115 ms. Here&apos;s the loop, the invariants, and what we don&apos;t cover.</description><pubDate>Sat, 06 Jun 2026 13:00:00 GMT</pubDate><category>fuzzing</category><category>reliability</category><category>canary</category><category>engineering</category><category>qa</category><author>OriginChainDB engineering (OriginChainDB)</author></item><item><title>Window functions, correlated subqueries, and 590 passing tests</title><link>https://originchaindb.com/blogs/window-functions-correlated-subqueries-590-tests</link><guid isPermaLink="false">originchain-blog:window-functions-correlated-subqueries-590-tests</guid><description>OriginChainDB&apos;s SQL surface just grew window functions and correlated subqueries. ROW_NUMBER / RANK / DENSE_RANK / LAG / LEAD / SUM-AVG-COUNT-MIN-MAX OVER plus EXISTS / IN / scalar correlated subqueries, all on the planner, all green across ~590 tests. Here&apos;s what works in v1, the cumulative-frame trade-off, and what&apos;s queued for v2.</description><pubDate>Sat, 06 Jun 2026 10:00:00 GMT</pubDate><category>sql</category><category>window-functions</category><category>correlated-subqueries</category><category>engineering</category><category>planner</category><author>OriginChainDB engineering (OriginChainDB)</author></item><item><title>RAG at 10M documents: the failure mode the four-vendor stack hides</title><link>https://originchaindb.com/blogs/rag-at-10m-documents-the-four-vendor-failure-mode</link><guid isPermaLink="false">originchain-blog:rag-at-10m-documents-the-four-vendor-failure-mode</guid><description>Production RAG at 10M documents is a 10-stage pipeline against four databases. The article that everyone shares this week gets the math right - and misses the silent cross-system version skew that quietly degrades the Stage 7 faithfulness check. Here is the failure mode, why it is unreachable on a single-engine database, and the code.</description><pubDate>Tue, 26 May 2026 08:00:00 GMT</pubDate><category>rag</category><category>vector-search</category><category>hybrid-search</category><category>engineering</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>From a 20-second dashboard to 300 ms: rethinking how we fetch tenant credentials</title><link>https://originchaindb.com/blogs/from-20s-dashboard-to-300ms</link><guid isPermaLink="false">originchain-blog:from-20s-dashboard-to-300ms</guid><description>Every dashboard page that hit a customer&apos;s tenant engine first ran a slow remote command to read the tenant credential off the instance. Cold path: 4–15 seconds with a tail at 20 s. Replacing it with a managed parameter store cut that to ~150 ms, with a backwards-compatible fallback and an opportunistic backfill.</description><pubDate>Tue, 12 May 2026 20:00:00 GMT</pubDate><category>infrastructure</category><category>performance</category><category>platform</category><category>operations</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>Auto-generated Idempotency-Key: the database SDK that doesn&apos;t ask you to think</title><link>https://originchaindb.com/blogs/auto-idempotency-key-sdk</link><guid isPermaLink="false">originchain-blog:auto-idempotency-key-sdk</guid><description>Every mutating call from our SDK now ships an Idempotency-Key UUID automatically. The user never types one. The check that had to land first wasn&apos;t &apos;does it work&apos; - it was &apos;is the engine&apos;s cache bounded enough that a fresh key per call won&apos;t OOM us.&apos;</description><pubDate>Tue, 12 May 2026 16:00:00 GMT</pubDate><category>sdk</category><category>dx</category><category>idempotency</category><category>api-design</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>OriginChainDB vs Redis: when each fits</title><link>https://originchaindb.com/blogs/vs-redis</link><guid isPermaLink="false">originchain-blog:vs-redis</guid><description>Redis is the gold standard for in-memory KV with sub-ms reads. OriginChainDB matches Redis at small scale and exceeds it on durability semantics, atomic multi-shape writes, and built-in vector search. Redis is right when your data fits in RAM; OriginChainDB when you want a primary-store with the same speed feel and AI-native shapes.</description><pubDate>Wed, 06 May 2026 10:26:12 GMT</pubDate><category>redis</category><category>comparison</category><category>key-value</category><category>performance</category><category>architecture</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>OriginChainDB vs Supabase: bundled stack vs focused database</title><link>https://originchaindb.com/blogs/vs-supabase</link><guid isPermaLink="false">originchain-blog:vs-supabase</guid><description>Supabase bundles Postgres + Auth + Storage + Realtime + Edge Functions for prototype velocity. OriginChainDB is a focused database substrate purpose-built for AI workloads. If you want batteries-included, pick Supabase; if you want the database to be excellent at AI shapes and you&apos;ll bring your own auth/storage, pick OriginChainDB.</description><pubDate>Wed, 06 May 2026 10:26:12 GMT</pubDate><category>supabase</category><category>comparison</category><category>postgres</category><category>architecture</category><category>ai-native</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>Backpressure done right: 429 + Retry-After in OriginChainDB</title><link>https://originchaindb.com/blogs/backpressure-429</link><guid isPermaLink="false">originchain-blog:backpressure-429</guid><description>When a database can&apos;t keep up with writes, it has two choices: refuse cleanly (graceful) or accept and silently fail later (catastrophic). OriginChainDB&apos;s per-API-key backpressure is HTTP 429 with a precise Retry-After. Polite clients recover within seconds; impolite ones never crash the substrate. Here&apos;s how it works.</description><pubDate>Wed, 06 May 2026 10:26:12 GMT</pubDate><category>backpressure</category><category>rate-limiting</category><category>design</category><category>reliability</category><category>api</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>The economics of agent memory at 100M tool calls/month</title><link>https://originchaindb.com/blogs/agent-memory-economics</link><guid isPermaLink="false">originchain-blog:agent-memory-economics</guid><description>An autonomous agent at 100M tool calls/month produces ~50 GB of trace data and ~75 GB of embeddings. Storage is the small line; what dominates is retention policy and re-embedding. The LLM call itself is 99.8% of the bill. Here&apos;s the actual math, with the four levers that move it.</description><pubDate>Wed, 06 May 2026 10:26:12 GMT</pubDate><category>cost</category><category>agent-memory</category><category>scaling</category><category>ttl</category><category>tutorial</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>OriginChainDB vs Postgres + pgvector: when each fits</title><link>https://originchaindb.com/blogs/vs-postgres-pgvector</link><guid isPermaLink="false">originchain-blog:vs-postgres-pgvector</guid><description>Postgres + pgvector is great for teams already running Postgres and adding vectors as a feature. OriginChainDB is purpose-built for AI-agent workloads with thousands of writes per session, atomic multi-shape transactions, and sub-millisecond reads. Honest comparison.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>postgres</category><category>pgvector</category><category>comparison</category><category>architecture</category><category>vector-database</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>OriginChainDB vs DynamoDB: when each fits</title><link>https://originchaindb.com/blogs/vs-dynamodb</link><guid isPermaLink="false">originchain-blog:vs-dynamodb</guid><description>DynamoDB is brilliant operational KV - flat fees, infinite scale, zero servers. OriginChainDB is right when vectors are first-class shapes, you need atomic multi-shape writes, and you&apos;re comfortable with a less-mature operational footprint in exchange for AI-shaped throughput.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>dynamodb</category><category>comparison</category><category>key-value</category><category>architecture</category><category>vector-database</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>OriginChainDB vs Pinecone: vectors with payloads vs vectors with sidecars</title><link>https://originchaindb.com/blogs/vs-pinecone</link><guid isPermaLink="false">originchain-blog:vs-pinecone</guid><description>Pinecone stores vectors and assumes your entity data lives elsewhere - you dual-write. OriginChainDB stores vectors as shapes co-located with parent entities, atomic in one write. If you&apos;re paying the dual-write architecture&apos;s tax today, here&apos;s the alternative.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>pinecone</category><category>vector-database</category><category>comparison</category><category>architecture</category><category>ann</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>Why we don&apos;t need a separate vector database</title><link>https://originchaindb.com/blogs/no-separate-vector-database</link><guid isPermaLink="false">originchain-blog:no-separate-vector-database</guid><description>A separate vector database is the wrong shape for AI-native applications. Vectors describe entities; entities have lifecycles. Splitting them across two systems creates dual-write bugs and operational overhead. The correct architecture is one substrate, multiple shapes.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>architecture</category><category>vector-database</category><category>design</category><category>ai-native</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>Per-key TTL: building agent memory that forgets</title><link>https://originchaindb.com/blogs/per-key-ttl-agent-memory</link><guid isPermaLink="false">originchain-blog:per-key-ttl-agent-memory</guid><description>AI agent memory is full of records that should expire on their own - tool-call traces, session caches, embedding refreshes. Per-key TTL on a fast K/V substrate gets you that pattern without sweeper jobs. Here&apos;s how OriginChainDB handles it and what it lets you build.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>ttl</category><category>agent-memory</category><category>ephemeral</category><category>design</category><category>tutorial</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>RAG at production scale: where the latency goes</title><link>https://originchaindb.com/blogs/rag-latency-budget</link><guid isPermaLink="false">originchain-blog:rag-latency-budget</guid><description>Production RAG has a 1-3 second latency budget for retrieval-and-generation. Most is the LLM. Database round-trips add up surprisingly fast - and are the easiest place to lose 200ms you didn&apos;t have. Walking through where the time goes with realistic numbers.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>rag</category><category>performance</category><category>latency</category><category>ann</category><category>tutorial</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>The cost of an AI feature at 100K, 1M, and 10M users</title><link>https://originchaindb.com/blogs/ai-feature-cost-model</link><guid isPermaLink="false">originchain-blog:ai-feature-cost-model</guid><description>AI features look free in the prototype phase, then the bill hits. LLM tokens dominate (95%), embeddings are small (3%), database is rounding error (2%). Here&apos;s a realistic per-user cost model with line items at each scale, and what to optimize first.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>pricing</category><category>cost</category><category>tutorial</category><category>scaling</category><category>llm</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>Idempotent tool calls: building reliable agent loops</title><link>https://originchaindb.com/blogs/idempotent-tool-calls</link><guid isPermaLink="false">originchain-blog:idempotent-tool-calls</guid><description>Production AI agents make tool calls that have side effects: emails, charges, webhooks. Network retries and LLM hallucinations mean you&apos;ll get the same call twice. Here&apos;s the idempotency-key playbook on OriginChainDB - atomic CAS + per-key TTL + the wait-for-result path.</description><pubDate>Tue, 05 May 2026 06:20:43 GMT</pubDate><category>agents</category><category>tool-calls</category><category>idempotency</category><category>reliability</category><category>tutorial</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>HA snapshot bootstrap: closing the failover cutover gap</title><link>https://originchaindb.com/blogs/ha-snapshot-bootstrap</link><guid isPermaLink="false">originchain-blog:ha-snapshot-bootstrap</guid><description>Most database failovers silently drop writes that landed while a new replica was being seeded. Here&apos;s how OriginChainDB&apos;s snapshot-based bootstrap closes that particular window - and, honestly, what it still does not protect you from.</description><pubDate>Mon, 04 May 2026 20:59:15 GMT</pubDate><category>ha</category><category>replication</category><category>architecture</category><category>durability</category><category>failover</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>OriginChainDB quickstart: zero to your first AI feature in 5 minutes</title><link>https://originchaindb.com/blogs/quickstart</link><guid isPermaLink="false">originchain-blog:quickstart</guid><description>Provision a managed instance, write a JSON record + vector embedding atomically, run a similarity search, hydrate the matched record. Five minutes, no schema migration, no glue code.</description><pubDate>Mon, 04 May 2026 20:59:15 GMT</pubDate><category>tutorial</category><category>quickstart</category><category>sdk</category><category>getting-started</category><category>vector-search</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>Why our roadmap to 1.0 is depth-first (and what&apos;s not on it)</title><link>https://originchaindb.com/blogs/depth-first-roadmap-to-1-0</link><guid isPermaLink="false">originchain-blog:depth-first-roadmap-to-1-0</guid><description>OriginChainDB&apos;s roadmap is HA → fuzzing → optimiser → EXPLAIN → multi-writer → online-schema. Six months. No graph, no FTS, no time-series specialty types until that&apos;s done. Here&apos;s why depth-first is the right bet for an AI-native database.</description><pubDate>Mon, 04 May 2026 20:59:15 GMT</pubDate><category>roadmap</category><category>product</category><category>design</category><category>architecture</category><author>OriginChainDB Team (OriginChainDB)</author></item><item><title>Eight competitor comparison pages, three parallel agents, one afternoon</title><link>https://originchaindb.com/blogs/eight-vs-pages-three-agents-one-afternoon</link><guid isPermaLink="false">originchain-blog:eight-vs-pages-three-agents-one-afternoon</guid><description>We shipped /vs/postgres, /vs/pinecone, /vs/weaviate, /vs/qdrant, /vs/milvus, /vs/supabase, /vs/neon, and /vs/mongodb in under an afternoon by running three Claude Code agents in parallel. The pattern, the prompt, and the part agents don&apos;t replace.</description><pubDate>Mon, 04 May 2026 16:00:00 GMT</pubDate><category>engineering</category><category>ai-tools</category><category>agents</category><category>marketing-site</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>Why we shipped a vanilla OpenAPI spec when nobody asked for one</title><link>https://originchaindb.com/blogs/openapi-spec-and-the-ai-coding-loop</link><guid isPermaLink="false">originchain-blog:openapi-spec-and-the-ai-coding-loop</guid><description>In 2026, engineers don&apos;t write SDKs - they ask their AI agent to. The agent fetches your OpenAPI spec, runs openapi-generator, and ships a working client in 30 seconds. If you don&apos;t have a spec, you don&apos;t exist in that loop.</description><pubDate>Mon, 04 May 2026 13:00:00 GMT</pubDate><category>openapi</category><category>ai-tools</category><category>sdk</category><category>developer-experience</category><author>OriginChainDB (OriginChainDB)</author></item><item><title>One MCP server, every AI IDE: OriginChainDB inside Claude Desktop and Cursor</title><link>https://originchaindb.com/blogs/mcp-server-launch</link><guid isPermaLink="false">originchain-blog:mcp-server-launch</guid><description>Database vendors who don&apos;t ship an MCP server in 2026 are invisible to the agents writing the code. Here&apos;s what @originchain/mcp-server exposes - five tools, stdio transport, env-var config - and what MCP doesn&apos;t yet solve.</description><pubDate>Mon, 04 May 2026 10:00:00 GMT</pubDate><category>mcp</category><category>ai-tools</category><category>claude</category><category>cursor</category><author>OriginChainDB (OriginChainDB)</author></item></channel></rss>