From 6e334f51d353ce885ac9055640f67d93421ce7c7 Mon Sep 17 00:00:00 2001 From: yusuf-gundogdu Date: Wed, 23 Sep 2026 19:35:42 +0300 Subject: [PATCH] Add weekly article submission: Schema is data too --- weekly/schema-is-data-too.yml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 weekly/schema-is-data-too.yml diff --git a/weekly/schema-is-data-too.yml b/weekly/schema-is-data-too.yml new file mode 100644 index 0000000..433d58b --- /dev/null +++ b/weekly/schema-is-data-too.yml @@ -0,0 +1,17 @@ +article: + link: "https://libredbstudio.hashnode.dev/schema-is-data-too-keeping-an-in-database-ai-assistant-inside-your-boundary" + author: + name: "LibreDB Studio" + linkedin: "" + twitter: "" + reviewer: + name: "" + linkedin: "" + twitter: "" + review: "A look at what a natural-language-to-SQL feature actually sends outside your network every time it answers a plain-English question. It names the three things that leave on a cloud path: the schema, any sample rows pulled in for context, and the business question itself, then argues for three controls that let you keep the assistant without giving up the boundary. The first is a swappable model endpoint, so teams can point the feature at a local runtime and keep the whole path inside the network. The second is read-only access enforced by the database itself rather than by a regex over the generated SQL, with the useful caveat that a read-only transaction still needs a least-privilege role behind it to mean anything. The third is a human review step before any generated query runs, which earns its keep as models get smaller and cheaper. Worth a read for anyone putting an LLM in front of a warehouse or a production database." + tags: + - text-to-sql + - nl2sql + - data-governance + - llm + - database-security