--- title: Data is the application | daily.dev description: Agentic coding has made most of software development reversible and fast: layouts, features, translations, and bugs can be redeployed in minutes if they don't... canonical: https://daily.dev/posts/data-is-the-application-8lig6hx9p twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Data is the application | daily.dev og:description: Agentic coding has made most of software development reversible and fast: layouts, features, translations, and bugs can be redeployed in minutes if they don't... og:url: https://daily.dev/posts/data-is-the-application-8lig6hx9p og:image: https://api.daily.dev/og/posts/8liG6HX9p.png og:image:alt: Data is the application og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Data is the application **[Mattias Geniar](https://daily.dev/sources/mattiasgeniar)** · 6 min read · 10 upvotes · 2 comments ## Summary Agentic coding has made most of software development reversible and fast: layouts, features, translations, and bugs can be redeployed in minutes if they don't work out. The one exception is the data layer, where migrations, schema choices, and retention decisions are effectively one-way doors. Even techniques like soft deletes and event sourcing only soften the blow rather than fully undo data loss, because an event never recorded can never be replayed. The author argues that thinking through what happens to existing data now takes more time than writing any migration, since UI and code can always be rebuilt but user data, once lost, cannot be reproduced. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why can't event sourcing fully undo a mistake in the data layer? Event sourcing only protects against broken tables, not lost information. Because the event log is append-only, a badly designed event stays in it forever, and any event that was never recorded in the first place can never be replayed. Rebuilding a table from events works, but if the underlying event data was wrong or missing, replaying it just reproduces the same problem. _Anyone weighing event sourcing tradeoffs can find deeper implementation discussions on daily.dev._ ### How do I undo a database migration that deleted data, like a truncated column? A migration's down() function only reverses the code change, not the data loss itself. Running down() after a migration truncated a column puts the column back, but it comes back empty, because the actual values were never preserved anywhere. Protecting against this requires backups taken before the migration runs, not just a reversible migration script. _Developers planning risky schema changes often compare backup and rollback strategies on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@quest4jolt** · 0 upvotes > Why not just use a version-controlled database like Dolt? It has rollback and as-of queries. > > High risk needs max control **@nark3d** · 0 upvotes > There's a reversibility asymmetry here, but it doesn't follow that the data layer is where the thinking happens, only where the mistakes are permanent. If code and UI can be rebuilt in minutes, the schema they're rebuilt against decides what those rebuilds are allowed to be. That decision gets made before anything reversible exists to test it on. So what's the process on the data side that's the equivalent of a redeploy - what does review look like when the artefact is a migration and the feedback loop is measured in months, not minutes? > > > https://prickles.org/tenet/schema-sovereignty/T4 ## Similar posts on daily.dev - [How you migrate is everything](https://daily.dev/posts/how-you-migrate-is-everything-hrw6satyt) · swizec.com · 22 upvotes · 0 comments - [Skip the learning curve: rethinking data migration for real outcomes](https://daily.dev/posts/skip-the-learning-curve-rethinking-data-migration-for-real-outcomes-2krcmgd6o) · databricks · 1 upvotes · 0 comments - [Continuous Delivery Office Hours Ep.5: Delivering database changes](https://daily.dev/posts/continuous-delivery-office-hours-ep-5-delivering-database-changes-qzfxcmmhw) · OctopusDeploy · 0 upvotes · 0 comments - [We'll End Up Where We Started. Except with Different Technology.](https://daily.dev/posts/we-ll-end-up-where-we-started-except-with-different-technology--5h7gm44uu) · Event Store · 0 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#database](https://daily.dev/tags/database), [#ai-coding](https://daily.dev/tags/ai-coding), [#data-privacy](https://daily.dev/tags/data-privacy) [View this post on daily.dev](https://daily.dev/posts/data-is-the-application-8lig6hx9p) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Data is the application","url":"https://daily.dev/posts/data-is-the-application-8lig6hx9p","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/data-is-the-application-8lig6hx9p"},"datePublished":"2026-09-29T18:56:37.359Z","dateModified":"2026-09-29T18:56:58.272Z","description":"Agentic coding has made most of software development reversible and fast: layouts, features, translations, and bugs can be redeployed in minutes if they don't...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0cf3fc1d82014b7b145cc818036fb325?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0cf3fc1d82014b7b145cc818036fb325?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Mattias Geniar","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Mattias Geniar","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/mattiasgeniar"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/data-is-the-application-8lig6hx9p","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"architecture,database,ai-coding,data-privacy","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Mattias Geniar","item":"https://daily.dev/sources/mattiasgeniar"},{"@type":"ListItem","position":3,"name":"Data is the application"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/data-is-the-application-8lig6hx9p","comment":[{"@type":"Comment","text":"Why not just use a version-controlled database like Dolt? It has rollback and as-of queries.\nHigh risk needs max control","datePublished":"2026-10-02T21:30:19.604Z","dateModified":"2026-10-02T21:33:18.901Z","url":"https://daily.dev/posts/8liG6HX9p#c-WpSQPqQiI","author":{"@type":"Person","name":"J-dawg","url":"https://daily.dev/quest4jolt","image":"https://lh3.googleusercontent.com/a/ACg8ocKhFgP1EkhUsabwdXHwFacFAAPl0xYwcWaTMOAcLVryCsQKQ30=s96-c"}},{"@type":"Comment","text":"There’s a reversibility asymmetry here, but it doesn’t follow that the data layer is where the thinking happens, only where the mistakes are permanent. If code and UI can be rebuilt in minutes, the schema they’re rebuilt against decides what those rebuilds are allowed to be. That decision gets made before anything reversible exists to test it on. So what’s the process on the data side that’s the equivalent of a redeploy - what does review look like when the artefact is a migration and the feedback loop is measured in months, not minutes?\nhttps://prickles.org/tenet/schema-sovereignty/T4","datePublished":"2026-10-04T10:28:46.748Z","url":"https://daily.dev/posts/8liG6HX9p#c-O51NNz1GW","author":{"@type":"Person","name":"Adam","url":"https://daily.dev/nark3d","image":"https://avatars.githubusercontent.com/u/2162621?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/data-is-the-application-8lig6hx9p#faq","mainEntity":[{"@type":"Question","name":"Why can't event sourcing fully undo a mistake in the data layer?","acceptedAnswer":{"@type":"Answer","text":"Event sourcing only protects against broken tables, not lost information. Because the event log is append-only, a badly designed event stays in it forever, and any event that was never recorded in the first place can never be replayed. Rebuilding a table from events works, but if the underlying event data was wrong or missing, replaying it just reproduces the same problem. Anyone weighing event sourcing tradeoffs can find deeper implementation discussions on daily.dev."}},{"@type":"Question","name":"How do I undo a database migration that deleted data, like a truncated column?","acceptedAnswer":{"@type":"Answer","text":"A migration's down() function only reverses the code change, not the data loss itself. Running down() after a migration truncated a column puts the column back, but it comes back empty, because the actual values were never preserved anywhere. Protecting against this requires backups taken before the migration runs, not just a reversible migration script. Developers planning risky schema changes often compare backup and rollback strategies on daily.dev."}}]} ```