If JSON is enough for your use case, go ahead, use it. The big RDBM systems support it rather well now, so you can bring it straight into the SQL world too. XM

If JSON is enough for your use case, go ahead, use it. The big RDBM systems support it rather well now, so you can bring it straight into the SQL world too. XML is for the non-trivial case, where having schemas and tooling around them for validation and code generation becomes useful. XML also has a default programming language for querying and transformations, allowing you to implement adapters from CSV, JSON or whatever into XML, and then between XML schemas. XML can be used in a JSON-like way if that's what you want: XPath. When programming against XML it's usually not what you want though, in practice it tends to be nicer to use the schema to set up an object hierarchy native to the programming language and unmarshal into that. But there is at least one XPath oriented database, eXist, and it's pretty ergonomic if you find yourself with a lot of XML and isn't sure what it contains or what to use it for. I find it easier to work with than the NoSQL JSON varieties I come across professionally, and when I have Questions For The Customer it craps out PDF:s I can send them, which doesn't seem that easy to do with Mongo or Firestore. As for SQL databases, they come in a lot of shapes and colours. I'm not so sure there is a JSON-first database equivalent of DuckDB, for example. Maybe I'm wrong, it's not a specialty of mine.