<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Database on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/database/</link><description>Recent content in Database on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 14 Jul 2026 10:04:25 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/database/index.xml" rel="self" type="application/rss+xml"/><item><title>IcefallDB: Time Travel on Plain Parquet Files</title><link>https://www.visorcraft.com/news/2026/07/icefalldb-time-travel-parquet/</link><pubDate>Tue, 14 Jul 2026 10:04:25 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/icefalldb-time-travel-parquet/</guid><description>&lt;p&gt;Parquet is the columnar format that ate the data lake, and for good reason: it compresses well, it reads fast, every analytics engine from DuckDB to Spark to DataFusion speaks it natively, and the files are just sitting there on disk waiting to be queried by anything that can open them, which is the same property that made SQLite appealing for a different class of problem. The catch, and it is a significant catch, is that Parquet is immutable by design, the format spec has no concept of updating a row in place, deleting a tuple, or merging two versions of a record, and the moment you need any of those operations you are in the business of rewriting files or building a layer on top that pretends mutability exists; IcefallDB is that layer, and the interesting work was making the pretension convincing enough that you stop noticing it.&lt;/p&gt;</description></item><item><title>grexa-db: a database where joins are directories of symlinks</title><link>https://www.visorcraft.com/news/2026/07/grexa-db-filesystem-joins/</link><pubDate>Sat, 11 Jul 2026 10:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/grexa-db-filesystem-joins/</guid><description>&lt;p&gt;Every database project starts with the same question: where does the data live? The conventional answers are a server process, a binary format, a set of memory-mapped pages, or a cloud endpoint. grexa-db answers differently: the data lives wherever your filesystem puts it, which means it lives everywhere your filesystem already goes, and the consequences of that choice are the interesting part.&lt;/p&gt;
&lt;p&gt;The short version is that grexa-db is a flat-file database engine where records are individual files and join relationships are directories full of symlinks, and the reason that matters is that every tool already written to read files from disk becomes, without modification, a query interface for your data: &lt;code&gt;rg&lt;/code&gt; searches records, &lt;code&gt;find&lt;/code&gt; traverses relationships, editors open rows, and your file-manager navigation habits become your database navigation habits, all without anyone involved having to know a database is present, though you do need &lt;code&gt;rg --follow&lt;/code&gt; or &lt;code&gt;find -L&lt;/code&gt; to traverse the join symlinks since most tools skip symlinks by default.&lt;/p&gt;</description></item></channel></rss>