<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Databases on F. Latini - IT Engineer</title><link>https://latini.dev/tags/databases/</link><description>Recent content in Databases on F. Latini - IT Engineer</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 22 Oct 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://latini.dev/tags/databases/index.xml" rel="self" type="application/rss+xml"/><item><title>Your Platform Stops at the Database</title><link>https://latini.dev/posts/your-platform-stops-at-the-database/</link><pubDate>Thu, 22 Oct 2026 08:00:00 +0000</pubDate><guid>https://latini.dev/posts/your-platform-stops-at-the-database/</guid><description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; - Most internal platforms will get a stateless service to production in an afternoon and then hand you a ticket form the moment you ask for a database. Platform teams pave the half that is cheap to get wrong, because a stateless mistake is undone by a redeploy and a data mistake is not undone at all. So the riskiest part of every service, the part where the mistakes are permanent, is the part with no road: provisioned by hand, accessed with a shared password, migrated by whoever is brave, and protected by backups nobody has ever restored. &amp;ldquo;We use a managed database&amp;rdquo; does not fix this, because the provider manages the engine and nothing about how your teams use it. Pave the data road the same way you paved the rest: a database from the template, access by identity, schema migrations run as deploys, restores as a drilled self-service command with a measured time, and a written line between what the platform owns and what the team owns.&lt;/p&gt;</description></item></channel></rss>