Databases always have a schema (2018)
The distinction between &quot;database schema&quot; and &quot;data type&quot; is the same impedance mismatch problem we&#x27;ve had for decades. You end up making an arbitrary transformation somewhere between your operational code and the persistence layer, at which time you have two different formats to represent your data. Any time you represent something twice, at least one of them is wrong, sooner or later.<p>The &quot;schema&quot; is the persistence-layer discussion of the contracts that programmers use to keep separate parts of the program consistent (even when they&#x27;re divided up among developers, or with yourself over time). The persistence layer may use that information to provide additional services that it can&#x27;t provide on a blob, like indexing. It&#x27;s &quot;natural&quot; to do that for performance reasons: you want to lay stuff out on the disk, and limit network traffic. But in terms of code maintenance, that&#x27;s optimization, and the root of all evil.<p>Few programming environments really take seriously the idea of eliminating that distinction. What I want is a language that pushes up notions like transactions and persistence right into the language itself, and let the compiler&#x2F;VM take care of whether a piece of data is persistent or not. Ideally, I&#x27;d love a programming environment that could just be shut off at any moment and restore itself transparently, including unwinding that had become out of date. I gather that Inferno took that approach, but I haven&#x27;t had a chance to use it.<p>The relevant bit of that is that it would eliminate the arbitrary distinction between &quot;database schema&quot; and the rest of your program. You&#x27;d use the same data specification for both, without a translator (or rather, with the translator completely hidden in the operating environment).