From 33880bc2d80fc7a36153469b15064dfe5823cb4b Mon Sep 17 00:00:00 2001
From: Mohammed Arshad Ansari <423442+arshadansari27@users.noreply.github.com>
Date: Mon, 31 Aug 2026 22:55:13 +0530
Subject: [PATCH] =?UTF-8?q?Add=20article:=20DuckDB=20in=20production=20?=
 =?UTF-8?q?=E2=80=94=20what=20it's=20actually=20good=20at=20(and=20what=20?=
 =?UTF-8?q?it=20isn't)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 weekly/duckdb-in-production-hikmah.yml | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 weekly/duckdb-in-production-hikmah.yml

diff --git a/weekly/duckdb-in-production-hikmah.yml b/weekly/duckdb-in-production-hikmah.yml
new file mode 100644
index 0000000..9ef6536
--- /dev/null
+++ b/weekly/duckdb-in-production-hikmah.yml
@@ -0,0 +1,17 @@
+article:
+  link: "https://hikmahtechnologies.com/blog/duckdb-in-production-what-its-good-at/"
+  author:
+    name: "Arshad Ansari"
+    linkedin: "https://www.linkedin.com/in/mohammed-arshad-ansari/"
+    twitter: ""
+  reviewer:
+    name: ""
+    linkedin: ""
+    twitter: ""
+  review: "An operator's account of where DuckDB fits in production and where it does not, written from systems the author runs rather than from benchmarks. It covers the three deployment patterns that hold up — in-process inside a service, containerised batch job, and a Parquet lake with many read-only readers — and names the anti-pattern behind most reliability complaints: several processes on a shared network filesystem all wanting write access to one file. The limitations section is unusually direct about single-process writes, the absence of a governance layer, and memory and spill behaviour, and it argues that the serving layer you end up writing yourself is the largest hidden line item in 'we'll just use DuckDB'."
+  tags:
+    - duckdb
+    - parquet
+    - local-first
+    - analytics
+    - data-architecture