<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Parquet on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/parquet/</link><description>Recent content in Parquet on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 29 Aug 2026 06:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/parquet/index.xml" rel="self" type="application/rss+xml"/><item><title>The filesystem as a database: SQLite, IcefallDB, and grexa-db</title><link>https://www.visorcraft.com/news/2026/08/filesystem-as-a-database-sqlite-icefalldb-grexa-db/</link><pubDate>Sat, 29 Aug 2026 06:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/filesystem-as-a-database-sqlite-icefalldb-grexa-db/</guid><description>&lt;p&gt;Ask a room of engineers where application data should live and you will get the same answer you would have gotten in 2005: put it in a database, pick Postgres if you are unsure, move on. The answer is not wrong, but it skips the interesting question, which is what your access pattern actually looks like once the feature ships, because a database is not a place to put data so much as a bet about how you will read it back, and three of our projects made three different bets that all landed on the same substrate: plain files on a filesystem, no server process, no wire protocol, no daemon between the data and the tools that read it.&lt;/p&gt;</description></item></channel></rss>