<?xml version='1.0' encoding='utf-8'?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
  <channel>
    <title>Database Articles by Franck Pachot</title>
    <link>https://franckpachot.github.io/pages/</link>
    <description>Recent database articles by Franck Pachot about PostgreSQL, Oracle Database, MongoDB, YugabyteDB, performance, and distributed systems.</description>
    <language>en</language>
    <atom:link href="https://franckpachot.github.io/pages/rss.xml" rel="self" type="application/rss+xml" />
    <lastBuildDate>Wed, 16 Sep 2026 00:00:00 +0000</lastBuildDate>
    <item>
      <title>Learn PostgreSQL extensibility through a gloriously bad idea: MM/DD/YYYY native datatype</title>
      <link>https://dev.to/franckpachot/learn-postgresql-extensions-through-a-gloriously-bad-idea-mmddyyyy-2pc4</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/learn-postgresql-extensions-through-a-gloriously-bad-idea-mmddyyyy-2pc4</guid>
      <pubDate>Wed, 16 Sep 2026 00:00:00 +0000</pubDate>
      <description>Uses an intentionally unsuitable MM/DD/YYYY base type to teach PostgreSQL extensibility, progressing from expression indexes to C-defined types and operators, a chronological B-tree operator class, and a multidimensional GiST operator class supporting wildcard containment and KNN seasonal-distance searches.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>extensions</category>
    </item>
    <item>
      <title>When Did This Transaction Happen? PostgreSQL Snapshots, LSNs, Oracle SCNs, and More</title>
      <link>https://dev.to/franckpachot/when-did-this-transaction-happen-postgresql-snapshots-lsns-oracle-scns-and-more-1369</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/when-did-this-transaction-happen-postgresql-snapshots-lsns-oracle-scns-and-more-1369</guid>
      <pubDate>Tue, 15 Sep 2026 00:00:00 +0000</pubDate>
      <description>Compares PostgreSQL snapshots and WAL LSNs, Oracle SCNs, YugabyteDB HybridTime, SQL Server XSNs, MySQL/InnoDB transaction and log coordinates, and MongoDB/WiredTiger logical times to distinguish visibility, commit order, durability, and wall-clock audit time.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>oracle</category>
      <category>database</category>
      <category>transactions</category>
    </item>
    <item>
      <title>Business Rules: Application Logic or Database Constraints? Both.</title>
      <link>https://www.linkedin.com/pulse/business-rules-application-logic-database-constraints-franck-pachot-mzh5e</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/business-rules-application-logic-database-constraints-franck-pachot-mzh5e</guid>
      <pubDate>Mon, 14 Sep 2026 00:00:00 +0000</pubDate>
      <description>Separates contextual business decisions from persistent data invariants, using overlapping room bookings to argue for application-level explanations and alternatives alongside PostgreSQL exclusion constraints that enforce concurrency-safe validity.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>PostgreSQL MVCC: Why Bloat Doesn't Automatically Mean Expensive Reads</title>
      <link>https://dev.to/franckpachot/postgresql-mvcc-why-bloat-doesnt-automatically-mean-expensive-reads-2pn7</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-mvcc-why-bloat-doesnt-automatically-mean-expensive-reads-2pn7</guid>
      <pubDate>Thu, 10 Sep 2026 00:00:00 +0000</pubDate>
      <description>Heap and index page experiments with autovacuum disabled show that PostgreSQL bloat does not imply proportional read amplification: sequential scans test tuples directly, index scans follow HOT chains only within a page, and reads opportunistically prune heap tuples and mark dead index entries LP_DEAD.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>mvcc</category>
    </item>
    <item>
      <title>Connecting Azure PostgreSQL to Oracle Autonomous with ORACLE_FDW</title>
      <link>https://techcommunity.microsoft.com/blog/adforpostgresql/connecting-azure-postgresql-to-oracle-autonomous-with-oracle-fdw/4547941</link>
      <guid isPermaLink="true">https://techcommunity.microsoft.com/blog/adforpostgresql/connecting-azure-postgresql-to-oracle-autonomous-with-oracle-fdw/4547941</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <description>Connects Azure Database for PostgreSQL to Oracle Autonomous Database through oracle_fdw, covering TLS, schema import, predicate and join pushdown, remote writes, migration, and post-migration comparison queries.</description>
      <category>Microsoft Tech Community</category>
    </item>
    <item>
      <title>NOT IN vs. NOT EXISTS: often a data modeling issue</title>
      <link>https://www.linkedin.com/pulse/vs-exists-often-data-modeling-issue-franck-pachot-3qzxe</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/vs-exists-often-data-modeling-issue-franck-pachot-3qzxe</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <description>Shows how NOT IN and NOT EXISTS express different NULL semantics, arguing that surprising anti-join results often reveal ambiguous requirements or nullable, denormalized relationships rather than a faulty SQL operator.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>PostgreSQL INCLUDE indexes: what problem are they trying to solve?</title>
      <link>https://dev.to/franckpachot/postgresql-include-indexes-what-problem-are-they-trying-to-solve-4f4n</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-include-indexes-what-problem-are-they-trying-to-solve-4f4n</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <description>Explains that PostgreSQL INCLUDE columns are non-key payload stored only in B-tree leaf tuples, allowing index-only scans without widening upper tree levels or changing key ordering and uniqueness semantics.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>index</category>
    </item>
    <item>
      <title>Skip Scan vs. Loose Index Scan</title>
      <link>https://dev.to/franckpachot/skip-scan-vs-loose-index-scan-51pn</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/skip-scan-vs-loose-index-scan-51pn</guid>
      <pubDate>Mon, 17 Aug 2026 00:00:00 +0000</pubDate>
      <description>PostgreSQL 18 experiments distinguish Skip Scan, which repositions across leading-key groups but returns every row matching a later-column predicate, from Loose Index Scan, which returns one representative per distinct prefix and still requires a recursive CTE workaround in PostgreSQL.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>performance</category>
    </item>
    <item>
      <title>OrioleDB Multi-Version Concurrency Control</title>
      <link>https://dev.to/franckpachot/orioledb-multi-version-concurrency-control-43d</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/orioledb-multi-version-concurrency-control-43d</guid>
      <pubDate>Sun, 16 Aug 2026 00:00:00 +0000</pubDate>
      <description>OrioleDB preserves historical predicate reachability with page-level undo in native B-trees and historical row values with row-level undo, while bridge indexes retain compatibility with PostgreSQL's other index access methods at the cost of extra lookup and cleanup work.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>orioledb</category>
    </item>
    <item>
      <title>Oracle to PostgreSQL in VS Code: Assessment, Conversion, and Validation</title>
      <link>https://techcommunity.microsoft.com/blog/adforpostgresql/oracle-to-postgresql-in-vs-code-assessment-conversion-and-validation/4544728</link>
      <guid isPermaLink="true">https://techcommunity.microsoft.com/blog/adforpostgresql/oracle-to-postgresql-in-vs-code-assessment-conversion-and-validation/4544728</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 +0000</pubDate>
      <description>Walks through an Oracle-to-PostgreSQL migration in VS Code, using model-assisted PL/SQL conversion plus executable tests for copied data, stored routines, business effects, and concurrent workload behavior.</description>
      <category>Microsoft Tech Community</category>
    </item>
    <item>
      <title>PostgreSQL Multi-Version: From Time Travel to Concurrency Control</title>
      <link>https://dev.to/franckpachot/postgresql-multi-version-from-time-travel-to-concurrency-control-b5</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-multi-version-from-time-travel-to-concurrency-control-b5</guid>
      <pubDate>Sun, 09 Aug 2026 00:00:00 +0000</pubDate>
      <description>Source history and direct heap experiments distinguish Berkeley POSTGRES multiversion storage for Time Travel from PostgreSQL's MVCC added in 1998, tracing how tuple versions later shaped snapshots, VACUUM, HOT, WAL, and contrasts with Oracle undo.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>oracle</category>
    </item>
    <item>
      <title>PostgreSQL 19 REPACK: Choosing the Right FILLFACTOR</title>
      <link>https://dev.to/franckpachot/postgresql-19-repack-choosing-the-right-fillfactor-3848</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-19-repack-choosing-the-right-fillfactor-3848</guid>
      <pubDate>Fri, 07 Aug 2026 00:00:00 +0000</pubDate>
      <description>A PostgreSQL 19 REPACK experiment shows that reusing an insert-oriented low FILLFACTOR can worsen bloat, while temporarily packing cold rows at 100% and then restoring HOT-update headroom balances space and WAL amplification.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>repack</category>
    </item>
    <item>
      <title>HorizonDB reduces WAL overhead with smarter FPI (full-page image) than traditional PostgreSQL</title>
      <link>https://dev.to/franckpachot/horizondb-reduces-wal-overhead-with-smarter-fpi-full-page-image-than-traditional-postgresql-1lhf</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/horizondb-reduces-wal-overhead-with-smarter-fpi-full-page-image-than-traditional-postgresql-1lhf</guid>
      <pubDate>Sun, 02 Aug 2026 00:00:00 +0000</pubDate>
      <description>A pgbench comparison using pg_stat_wal, pg_stat_checkpointer, and pg_stat_io shows HorizonDB's disaggregated storage avoids checkpoint-driven full-page images, cutting VACUUM WAL about twentyfold while retaining base-page images for storage.</description>
      <category>Dev.to</category>
      <category>horizondb</category>
      <category>azure</category>
      <category>postgres</category>
      <category>database</category>
    </item>
    <item>
      <title>AI-Powered Retrieval in PostgreSQL with Azure HorizonDB</title>
      <link>https://techcommunity.microsoft.com/blog/adforpostgresql/ai-powered-retrieval-in-postgresql-with-azure-horizondb/4540160</link>
      <guid isPermaLink="true">https://techcommunity.microsoft.com/blog/adforpostgresql/ai-powered-retrieval-in-postgresql-with-azure-horizondb/4540160</guid>
      <pubDate>Tue, 28 Jul 2026 00:00:00 +0000</pubDate>
      <description>Builds a movie search demo on HorizonDB combining pg_textsearch BM25, pgvector embeddings, and DiskANN indexing to keep AI retrieval logic inside PostgreSQL SQL rather than external workers.</description>
      <category>Microsoft Tech Community</category>
    </item>
    <item>
      <title>WHERE $1::timestamptz IS NULL OR "timestamp" &gt; $1</title>
      <link>https://dev.to/franckpachot/where-1timestamptz-is-null-or-timestamp-1-55kf</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/where-1timestamptz-is-null-or-timestamp-1-55kf</guid>
      <pubDate>Mon, 27 Jul 2026 00:00:00 +0000</pubDate>
      <description>A single PostgreSQL prepared statement with WHERE $1 IS NULL OR ts &gt; $1 serves both the first unfiltered page and cursor-paginated pages, replacing MongoDB's two separate query branches.</description>
      <category>Dev.to</category>
      <category>database</category>
      <category>performance</category>
      <category>postgres</category>
      <category>sql</category>
    </item>
    <item>
      <title>Following ROWIDs Through an Oracle Unique Index Update</title>
      <link>https://dev.to/franckpachot/following-rowids-through-an-oracle-unique-index-update-2lc</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/following-rowids-through-an-oracle-unique-index-update-2lc</guid>
      <pubDate>Sun, 26 Jul 2026 00:00:00 +0000</pubDate>
      <description>Oracle lets UPDATE swap two unique column values (-1 and 1) without violating the constraint mid-statement, while PostgreSQL rejects it unless the constraint is declared DEFERRABLE.</description>
      <category>Dev.to</category>
      <category>oracle</category>
      <category>postgres</category>
      <category>sql</category>
      <category>index</category>
    </item>
    <item>
      <title>B-tree block split: what's the impact?</title>
      <link>https://dev.to/franckpachot/b-tree-block-split-whats-the-impact-1i9c</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/b-tree-block-split-whats-the-impact-1i9c</guid>
      <pubDate>Fri, 24 Jul 2026 00:00:00 +0000</pubDate>
      <description>Inserting rows one at a time into a PostgreSQL B-tree while tracking EXPLAIN buffers, WAL, and pageinspect/pgstattuple output reveals exactly when pages split and the tree gains a level.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>btree</category>
    </item>
    <item>
      <title>B+tree height after full delete: PostgreSQL fast root</title>
      <link>https://dev.to/franckpachot/btree-height-after-delete-oracle-rebuild-vs-postgresql-fastroot-1ia4</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/btree-height-after-delete-oracle-rebuild-vs-postgresql-fastroot-1ia4</guid>
      <pubDate>Thu, 23 Jul 2026 00:00:00 +0000</pubDate>
      <description>After deleting every row from a table, PostgreSQL's B-tree index collapses back to a single-page root via its fast-root optimization instead of keeping the multi-level structure built during inserts.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>oracle</category>
      <category>sql</category>
      <category>database</category>
    </item>
    <item>
      <title>The Myth of Strong Relationships in Relational Databases</title>
      <link>https://www.linkedin.com/pulse/myth-strong-relationships-relational-databases-franck-pachot-b4xoe</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/myth-strong-relationships-relational-databases-franck-pachot-b4xoe</guid>
      <pubDate>Wed, 22 Jul 2026 00:00:00 +0000</pubDate>
      <description>Clarifies that relational means mathematical relations rather than business relationships, and argues normalization removes structural associations that foreign keys, joins, and transactions must then reconstruct.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>From Joins to Graph Edges: SQL/PGQ in PostgreSQL 19</title>
      <link>https://dev.to/franckpachot/from-joins-to-graph-edges-sqlpgq-in-postgresql-19-2doo</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/from-joins-to-graph-edges-sqlpgq-in-postgresql-19-2doo</guid>
      <pubDate>Wed, 22 Jul 2026 00:00:00 +0000</pubDate>
      <description>PostgreSQL 19's SQL/PGQ defines a property graph as a query-time semantic layer over existing EMP/DEPT-style relational tables, unlike Apache AGE which materializes vertices and edges as stored data.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>graph</category>
      <category>database</category>
    </item>
    <item>
      <title>Cypher graph queries on PostgreSQL with Apache AGE</title>
      <link>https://dev.to/franckpachot/cypher-graph-queries-on-postgresql-with-apache-age-3l62</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/cypher-graph-queries-on-postgresql-with-apache-age-3l62</guid>
      <pubDate>Tue, 21 Jul 2026 00:00:00 +0000</pubDate>
      <description>The Apache AGE extension lets PostgreSQL run Cypher queries over an EMP/DEPT hierarchy, tracing graph traversal back through Oracle's 1980s CONNECT BY syntax and SQL's recursive WITH clause.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>graph</category>
      <category>database</category>
      <category>vscode</category>
    </item>
    <item>
      <title>DocumentDB on YugabyteDB</title>
      <link>https://dev.to/franckpachot/documentdb-on-yugabytedb-4na0</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/documentdb-on-yugabytedb-4na0</guid>
      <pubDate>Fri, 17 Jul 2026 00:00:00 +0000</pubDate>
      <description>YugabyteDB 2026.1 previews the DocumentDB extension for MongoDB compatibility, launched via preview flags in a Docker container, though it still lacks secondary indexes and ARM support.</description>
      <category>Dev.to</category>
      <category>documentdb</category>
      <category>postgres</category>
      <category>database</category>
      <category>yugabytedb</category>
    </item>
    <item>
      <title>PostgreSQL as a converged database with pglayers-full</title>
      <link>https://dev.to/franckpachot/postgresql-as-a-converged-database-with-pglayers-full-2a7h</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-as-a-converged-database-with-pglayers-full-2a7h</guid>
      <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
      <description>The ghcr.io/pglayers/pglayers-full Docker image bundles PostgreSQL with a large extension set, including a pre-installed DocumentDB extension exposing a MongoDB-compatible endpoint out of the box.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>mongodb</category>
      <category>database</category>
    </item>
    <item>
      <title>“PostgreSQL resolves uniqueness through heap tuple visibility”</title>
      <link>https://dev.to/franckpachot/postgresql-resolves-uniqueness-through-heap-tuple-visibility-bkp</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-resolves-uniqueness-through-heap-tuple-visibility-bkp</guid>
      <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
      <description>Unlike Oracle, where unique B-tree keys alone prevent duplicates, PostgreSQL appends the tuple ID to every index entry, enforcing uniqueness at the heap-visibility level for MVCC.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>database</category>
      <category>index</category>
      <category>internals</category>
    </item>
    <item>
      <title>What happens when a PostgreSQL backend crashes?</title>
      <link>https://dev.to/franckpachot/what-happens-when-a-postgresql-backend-crashes-3md</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/what-happens-when-a-postgresql-backend-crashes-3md</guid>
      <pubDate>Tue, 07 Jul 2026 00:00:00 +0000</pubDate>
      <description>Killing one PostgreSQL backend during a pgbench run terminates every other connection too, because shared memory is assumed corrupted, forcing full crash recovery before new connections are accepted.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>database</category>
      <category>architecture</category>
      <category>tutorial</category>
    </item>
    <item>
      <title>PostgreSQL query planner parameters and prepared statements</title>
      <link>https://dev.to/franckpachot/postgresql-query-planner-parameters-and-prepared-statements-3o5a</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-query-planner-parameters-and-prepared-statements-3o5a</guid>
      <pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
      <description>Testing enable_seqscan and similar planner settings around PREPARE and EXECUTE on a partially indexed 500-row tasks table shows these parameters affect only planning, not a cached generic plan.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>performance</category>
    </item>
    <item>
      <title>Extended RUM in DocumentDB: B-tree-like ordered scans for flexible BSON in PostgreSQL</title>
      <link>https://dev.to/franckpachot/extended-rum-in-documentdb-b-tree-like-ordered-scans-for-flexible-bson-in-postgresql-4nje</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/extended-rum-in-documentdb-b-tree-like-ordered-scans-for-flexible-bson-in-postgresql-4nje</guid>
      <pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate>
      <description>DocumentDB's Extended RUM access method builds composite index terms with an ordering transform, letting it filter, sort, and stop at LIMIT in one Index Scan over flexible BSON arrays.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>documentdb</category>
      <category>mongodb</category>
      <category>database</category>
    </item>
    <item>
      <title>kernel asynchronous reads in PostgreSQL 19 (io_uring)</title>
      <link>https://dev.to/franckpachot/iouring-buffered-reads-in-postgresql-19-iouring-mcn</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/iouring-buffered-reads-in-postgresql-19-iouring-mcn</guid>
      <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
      <description>Running the same async sequential scan with io_method=io_uring in a seccomp-unconfined Docker container shows PostgreSQL 19 issuing kernel-level io_uring calls instead of worker pread64.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>database</category>
      <category>linux</category>
      <category>io</category>
    </item>
    <item>
      <title>Multi-block buffered reads in PostgreSQL 19 (IO combine &amp; prefetch)</title>
      <link>https://dev.to/franckpachot/multi-block-buffered-reads-in-postgresql-19-io-combine-prefetch-3dl2</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/multi-block-buffered-reads-in-postgresql-19-io-combine-prefetch-3dl2</guid>
      <pubDate>Tue, 30 Jun 2026 00:00:00 +0000</pubDate>
      <description>PostgreSQL 19's read stream layer groups adjacent 8KB blocks into larger reads up to io_combine_limit during Seq Scan and Bitmap Heap Scan, cutting per-block pread64 system-call overhead.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>performance</category>
      <category>linux</category>
      <category>io</category>
    </item>
    <item>
      <title>Hybrid Search (Full-Text and Vector Similarity) in HorizonDB</title>
      <link>https://dev.to/franckpachot/hybrid-search-full-text-and-vector-similarity-in-horizondb-3a5f</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/hybrid-search-full-text-and-vector-similarity-in-horizondb-3a5f</guid>
      <pubDate>Mon, 29 Jun 2026 00:00:00 +0000</pubDate>
      <description>A synthetic product catalog on Azure HorizonDB compares BM25-then-vector cascade, vector-then-BM25 cascade, and parallel-fusion hybrid search, showing each combination trades recall against speed.</description>
      <category>Dev.to</category>
      <category>horizondb</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
    </item>
    <item>
      <title>Azure AI on HorizonDB (Microsoft Foundry Azure OpenAI from SQL)</title>
      <link>https://dev.to/franckpachot/azure-ai-on-horizondb-fbk</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/azure-ai-on-horizondb-fbk</guid>
      <pubDate>Sat, 27 Jun 2026 00:00:00 +0000</pubDate>
      <description>A four-step walkthrough enables the azure_ai extension via azure.extensions, then registers an Azure OpenAI endpoint so azure_ai.generate() can call generative models directly from SQL.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>microsoft</category>
      <category>azure</category>
      <category>ai</category>
    </item>
    <item>
      <title>$lookup join strategies: understanding the trade-offs with flexible documents</title>
      <link>https://dev.to/franckpachot/lookup-join-strategies-understanding-the-trade-offs-with-flexible-documents-ncf</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/lookup-join-strategies-understanding-the-trade-offs-with-flexible-documents-ncf</guid>
      <pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate>
      <description>Running $lookup on the open-source DocumentDB extension for PostgreSQL shows how flexible field semantics like arrays restrict join optimization compared to MongoDB's native join strategies.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>documentdb</category>
      <category>mongodb</category>
      <category>database</category>
    </item>
    <item>
      <title>Oracle FDW on Azure Database for PostgreSQL</title>
      <link>https://dev.to/franckpachot/oracle-fdw-on-azure-database-for-postgresql-510c</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/oracle-fdw-on-azure-database-for-postgresql-510c</guid>
      <pubDate>Thu, 25 Jun 2026 00:00:00 +0000</pubDate>
      <description>Enabling the oracle_fdw wrapper on Azure Database for PostgreSQL only requires listing it in azure.extensions before CREATE EXTENSION, since the service runs community PostgreSQL.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>azure</category>
      <category>oracle</category>
      <category>migration</category>
    </item>
    <item>
      <title>Vector Search with Filters: pgvector vs DiskANN on HorizonDB</title>
      <link>https://dev.to/franckpachot/vector-search-with-filters-pgvector-vs-diskann-on-horizondb-i2k</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/vector-search-with-filters-pgvector-vs-diskann-on-horizondb-i2k</guid>
      <pubDate>Mon, 22 Jun 2026 00:00:00 +0000</pubDate>
      <description>On a 2 vCore HorizonDB instance, filtered similarity search compares pgvector's HNSW index against Microsoft's DiskANN index, both combining a WHERE clause with an ORDER BY &lt;=&gt; vector query.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>vector</category>
      <category>database</category>
    </item>
    <item>
      <title>HorizonDB cache hierarchy: RAM, NVMe SSD, and multi-AZ storage behind PostgreSQL</title>
      <link>https://dev.to/franckpachot/horizondb-cache-hierarchy-ram-nvme-ssd-and-multi-az-storage-behind-postgresql-k82</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/horizondb-cache-hierarchy-ram-nvme-ssd-and-multi-az-storage-behind-postgresql-k82</guid>
      <pubDate>Wed, 17 Jun 2026 00:00:00 +0000</pubDate>
      <description>EXPLAIN BUFFERS hit ratios, average read-time metrics, and wait events reveal HorizonDB's three storage tiers behind standard PostgreSQL: shared-buffer RAM, local NVMe SSD cache, and remote storage.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>azure</category>
      <category>cloud</category>
      <category>database</category>
    </item>
    <item>
      <title>Provision PostgreSQL from VS Code</title>
      <link>https://www.linkedin.com/pulse/provision-postgresql-from-vs-code-franck-pachot-q4ede</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/provision-postgresql-from-vs-code-franck-pachot-q4ede</guid>
      <pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate>
      <description>Walks through using Microsoft's PostgreSQL extension for VS Code to create connections and provision local Docker or managed cloud PostgreSQL instances without leaving the editor.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>HorizonDB preview: automate a reproducible lab with ARM</title>
      <link>https://dev.to/franckpachot/horizondb-preview-automate-a-reproducible-lab-with-arm-2515</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/horizondb-preview-automate-a-reproducible-lab-with-arm-2515</guid>
      <pubDate>Fri, 12 Jun 2026 00:00:00 +0000</pubDate>
      <description>An Azure Resource Manager template, deployed via the Azure CLI after az login, automates spinning up and tearing down a reproducible HorizonDB preview lab without manual portal clicks.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>azure</category>
      <category>horizondb</category>
      <category>cloud</category>
    </item>
    <item>
      <title>PostgreSQL Average Active Sessions Dashboard in VS Code</title>
      <link>https://www.linkedin.com/pulse/postgresql-average-active-sessions-dashboard-vs-code-franck-pachot-u1kre</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/postgresql-average-active-sessions-dashboard-vs-code-franck-pachot-u1kre</guid>
      <pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate>
      <description>Uses the PostgreSQL VS Code extension's performance dashboard to visualize average active sessions, wait types, ranked wait events, blockers, and pg_stat_activity details during pgbench contention.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>RUM—Storing More in the Index</title>
      <link>https://dev.to/franckpachot/rum-storing-more-in-the-index-4hoe</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/rum-storing-more-in-the-index-4hoe</guid>
      <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
      <description>RUM, built by Alexander Korotkov and colleagues at Postgres Professional, extends each GIN posting-list entry with an extra datum alongside the TID to fix full-text ranking and ordering performance.</description>
      <category>Dev.to</category>
      <category>architecture</category>
      <category>database</category>
      <category>performance</category>
      <category>postgres</category>
    </item>
    <item>
      <title>GIN: Understanding PostgreSQL's Inverted Index and Its Limitations</title>
      <link>https://dev.to/franckpachot/gin-understanding-postgresqls-inverted-index-and-its-limitations-40hn</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/gin-understanding-postgresqls-inverted-index-and-its-limitations-40hn</guid>
      <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
      <description>GIN decomposes arrays, JSONB, and tsvector values into an entry B-tree of keys pointing to posting lists of heap TIDs, saving space but leaving range queries and sorting unsupported.</description>
      <category>Dev.to</category>
      <category>architecture</category>
      <category>database</category>
      <category>performance</category>
      <category>postgres</category>
    </item>
    <item>
      <title>Extended RUM in DocumentDB extension for PostgreSQL: Efficient ESR (Equality, Sort, Range) Queries</title>
      <link>https://dev.to/franckpachot/extended-rum-in-documentdb-extension-for-postgresql-efficient-esr-equality-sort-range-queries-5bkj</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/extended-rum-in-documentdb-extension-for-postgresql-efficient-esr-equality-sort-range-queries-5bkj</guid>
      <pubDate>Sun, 07 Jun 2026 00:00:00 +0000</pubDate>
      <description>A year after finding RUM indexes couldn't replace MongoDB compound indexes for sorted queries, the May 2026 DocumentDB extension's Extended RUM index preserves key ordering for pagination.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>document</category>
      <category>database</category>
    </item>
    <item>
      <title>Getting Started with pg_durable: Workflows Inside PostgreSQL</title>
      <link>https://dev.to/franckpachot/getting-started-with-pgdurable-durable-workflows-inside-postgresql-3980</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/getting-started-with-pgdurable-durable-workflows-inside-postgresql-3980</guid>
      <pubDate>Fri, 05 Jun 2026 00:00:00 +0000</pubDate>
      <description>Building the pg_durable extension from source with Rust and pgrx on PostgreSQL 17 shows how it orchestrates crash-resilient, SQL-defined workflows for ETL and long-running background jobs.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>workflow</category>
    </item>
    <item>
      <title>Filter on Children, Sort by Parent: One-to-Many Compound Index Strategies in PostgreSQL</title>
      <link>https://dev.to/franckpachot/filter-on-children-sort-by-parent-one-to-many-compound-index-strategies-in-postgresql-1clj</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/filter-on-children-sort-by-parent-one-to-many-compound-index-strategies-in-postgresql-1clj</guid>
      <pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate>
      <description>Approximating a MongoDB compound index over embedded children in PostgreSQL requires denormalizing onto the parent or child row and maintaining consistency with cascading foreign keys or triggers.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>documentdb</category>
      <category>mongodb</category>
    </item>
    <item>
      <title>BSON and OSON: documents are designed to be nested, not flat</title>
      <link>https://dev.to/franckpachot/bson-and-oson-documents-are-designed-to-be-nested-not-flat-3b65</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/bson-and-oson-documents-are-designed-to-be-nested-not-flat-3b65</guid>
      <pubDate>Sat, 30 May 2026 00:00:00 +0000</pubDate>
      <description>Critiquing Oracle's YCSB and flat-document OSON benchmarks against BSON, it argues thousands of nested fields per document are acceptable in a document model, unlike flat SQL tables.</description>
      <category>Dev.to</category>
      <category>document</category>
      <category>database</category>
      <category>oracle</category>
      <category>mongodb</category>
    </item>
    <item>
      <title>$exists and non-sparse indexes in MongoDB and in other DocumentDB</title>
      <link>https://dev.to/franckpachot/exists-and-non-sparse-indexes-in-mongodb-and-in-other-documentdb-19e3</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/exists-and-non-sparse-indexes-in-mongodb-and-in-other-documentdb-19e3</guid>
      <pubDate>Fri, 29 May 2026 00:00:00 +0000</pubDate>
      <description>MongoDB indexes store null as a stand-in for a missing field, so a regular index scan can't distinguish $exists:false from an explicit null; only a partial index preserves that distinction.</description>
      <category>Dev.to</category>
      <category>mongodb</category>
      <category>documentdb</category>
      <category>postgres</category>
      <category>database</category>
    </item>
    <item>
      <title>The Autovacuum Scale Factor Problem at Scale - Know Your Defaults</title>
      <link>https://dev.to/franckpachot/the-autovacuum-scale-factor-problem-at-scale-know-your-defaults-5a9o</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/the-autovacuum-scale-factor-problem-at-scale-know-your-defaults-5a9o</guid>
      <pubDate>Tue, 26 May 2026 00:00:00 +0000</pubDate>
      <description>PostgreSQL's autovacuum threshold combines a fixed row count with a scale-factor percentage of table size, so tables with lots of cold, static data get inflated thresholds that delay maintenance.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>sql</category>
      <category>database</category>
      <category>performane</category>
    </item>
    <item>
      <title>Avoiding range overlaps in PostgreSQL with EXCLUDE constraint, better than serializable or assertions</title>
      <link>https://dev.to/franckpachot/postgresql-exclude-constraints-for-better-concurrency-than-serializable-pob</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/postgresql-exclude-constraints-for-better-concurrency-than-serializable-pob</guid>
      <pubDate>Fri, 15 May 2026 00:00:00 +0000</pubDate>
      <description>An EXCLUDE constraint with the range overlap operator stops two seat-range bookings like 5-8 and 7-9 from colliding, enforcing the invariant without serializable isolation or SQL assertions.</description>
      <category>Dev.to</category>
      <category>postgres</category>
      <category>oracle</category>
      <category>sql</category>
      <category>database</category>
    </item>
    <item>
      <title>PostgreSQL’s "random_page_cost" isn’t just about disk latency — and the default is often right when your indexes are</title>
      <link>https://www.linkedin.com/pulse/postgresqls-randompagecost-isnt-just-disk-latency-default-pachot-fphre</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/postgresqls-randompagecost-isnt-just-disk-latency-default-pachot-fphre</guid>
      <pubDate>Thu, 14 May 2026 00:00:00 +0000</pubDate>
      <description>Explains that PostgreSQL random_page_cost models cache behavior and CPU work as well as storage latency, so lowering it merely because disks are SSDs can produce worse plans.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>You need foreign keys and surrogate keys because you broke your relationships</title>
      <link>https://www.linkedin.com/pulse/you-need-foreign-keys-surrogate-because-broke-your-franck-pachot-wh0ne</link>
      <guid isPermaLink="true">https://www.linkedin.com/pulse/you-need-foreign-keys-surrogate-because-broke-your-franck-pachot-wh0ne</guid>
      <pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate>
      <description>Explains how normalization decomposes aggregates and thereby creates the need for surrogate keys, foreign keys, joins, and wider transactions that embedded document structures avoid within an aggregate.</description>
      <category>LinkedIn</category>
    </item>
    <item>
      <title>Do you need foreign keys and surrogate keys because you broke your relationships ?</title>
      <link>https://dev.to/franckpachot/you-need-foreign-keys-and-surrogate-keys-because-you-broke-your-relationships-3b0j</link>
      <guid isPermaLink="true">https://dev.to/franckpachot/you-need-foreign-keys-and-surrogate-keys-because-you-broke-your-relationships-3b0j</guid>
      <pubDate>Sat, 09 May 2026 00:00:00 +0000</pubDate>
      <description>Argues that normalizing a domain model into separate tables is what creates the need for foreign keys, reversing the common belief that related data itself requires a relational schema.</description>
      <category>Dev.to</category>
      <category>architecture</category>
      <category>database</category>
      <category>sql</category>
      <category>document</category>
    </item>
  </channel>
</rss>