Rust should treat enums as a first-class database primitive

32/2026 shows Rust teams rebuilding database types because SQL still lacks real enums.

Rust developers keep running into the same wall: once a system grows beyond flat rows and strings, the database becomes the weakest part of the type story. In the current forum thread, one builder of database software is already planning tuples, structs, enums, lists, maps, and sets, and that is not an edge case. It is what happens when a language with strong algebraic data types meets storage that still treats rich values as an afterthought.

SQL’s type model is too thin for modern application data

The first argument is simple: application data is no longer just scalar columns, and SQL’s legacy type system forces developers to flatten everything. The forum post about database software makes that obvious. The author is not asking for novelty; they are trying to preserve the shape of real Rust data in storage, which means nested records, tagged unions, and collections. When a database cannot represent those shapes directly, the application has to fake them with join tables, JSON blobs, or hand-rolled encoding rules.

This is not just a taste issue. It is a correctness issue. A Rust enum with variants carrying different payloads is a precise model of state, while a SQL enum is usually just a constrained string. That gap matters because the database is where invariants should live. If the storage layer cannot express the domain clearly, then every service that reads it must reimplement the same validation logic, and every migration becomes a gamble.

Rust will keep pushing storage toward richer primitives

The second argument is that Rust’s ecosystem is already moving in this direction, because Rust developers expect the type system to extend past the compiler and into persistence. The thread’s database author is not alone. Another participant described moving a spectrogram pipeline to the GPU and building toward commercial use with Vulkan, slang, and ring buffers. That kind of systems work depends on exact data layouts and predictable transformations. Once teams start thinking that way, the database has to meet them with more than primitive columns and ad hoc serialization.

There is also a practical reason this pressure will grow: Rust makes illegal states hard to represent in memory, and developers do not want to lose that benefit at the storage boundary. If a service models a domain with structs, enums, and options, then forcing it to round-trip through lossy SQL shapes introduces bugs at the seams. The result is a split-brain architecture where the Rust code is disciplined but the database is permissive. That is backward. The storage layer should be the strictest part of the stack, not the loosest.

The counter-argument

The strongest objection is that SQL’s simplicity is its strength. Relational databases have survived because they favor portability, mature tooling, and predictable query planning over expressive value types. A basic enum column is enough for many systems, and anything richer can be represented with normalized tables or JSON. From this view, asking the database to understand Rust-like enums is a category mistake. The database should store data, not mirror a programming language’s type algebra.

That objection is partly right. Not every schema needs variants with payloads, and not every team wants the operational cost of a more expressive storage engine. But the rebuttal is decisive: the current workarounds already impose complexity, they just hide it in application code, migrations, and serialization layers. If a domain truly has structured variants, encoding them as strings or JSON does not simplify the system. It only moves the complexity to places where the database can no longer enforce it.

What to do with this

If you are an engineer or founder building Rust-backed systems, stop treating rich data types as an application-only concern. Model the domain first, then choose storage that can preserve that model without flattening it. Use explicit schema boundaries, favor databases and extensions that can represent structured values cleanly, and reject designs that force enums, tuples, and nested records into stringly typed columns. The goal is not to make SQL look like Rust. The goal is to keep your invariants intact from memory to disk.