No subject

<br>
- As you mentioned, it cannot only do a fixed number of operations per<br>
transaction<br>
<br>
- It also cannot touch the same item twice in one transaction.<br>
<br>
- It is not type safe, everything is a string, so everything that is<br>
written must be serialized to strings, and everything that is read must<br>
be parsed from strings, which is more complex and also much slower than<br>
simple data serialization. It also requires more exception handling code<br=
>
and creates a greater potential for software bugs.<br>
<br>
- Etcd is only a key/value store, so it does not have a structure<br>
(tables, rows, columns). Therefore, multiple columns belonging to one<br>
key must be either serialized into multiple key/value paris (increasing<br>
the number of operations per transaction) or the columns must be<br>
serialized into one string (increasing complexity due to the additional<br>
parsing)<br>
<br>
- It does not support constraints, such as foreign key constraints,<br>
checks of the values that go into it, etc., you could e.g. store a<br>
TCP/IP-Port number of -70,000 just fine, or a duplicate one, while a<br>
DBMS would have prevented such incorrect entries even in the presence of<br=
>
a bug in LINSTOR code. That makes the data less robust than it would be<br>
when stored in a DBMS.<br>
<br>
- It cannot combine entries or their fields, e.g. like an SQL JOIN can,<br>
so that must be coded into our software if required<br>
<br>
- We cannot automatically transform it as we can with a DBMS. It cannot<br>
be instructed to &quot;put all values from this table into this other table=
&quot;<br>
or &quot;change all the values where this condition matches&quot;. Transfor=
mations<br>
typically require parsing and loading all the affected entries, then<br>
writing our own logic to make any changes, and then serializing and<br>
storing all the entries again.<br>
<br>
- It is far less maintainable. Finding, changing or deleting one or<br>
multiple entries, or just fields of some entries, is quite simple if you<br=
>
can just type in some SQL manually. There is nothing like that in etcd.<br>
<br>
<br>
It&#39;s just marginally better than writing to files (at least it offers<b=
r>
some kind of transactions). But apart from that, put bluntly, it&#39;s a bi=
t<br>
like going back to the 1960s.<br>
<br>
<br>
But to be fair, even supporting multiple SQL databases is not as<br>
carefree as it might seem. I like to jokingly call any database a<br>
NoSQL-database, because none of the SQL databases actually implements<br>
SQL, they all implement a chaotic mix of subsets, supersets and<br>
variations of SQL. I&#39;m tempted to say that SQL doesn&#39;t even exist i=
n the<br>
real world, except as an idea in a book that noone ever read after it<br>
was written.<br>
That being said, due to some kind of a miracle, we&#39;re still able to run=
<br>
four different databases with the same database driver in LINSTOR, with<br>
only few conditional changes here and there.<br>
<br>
&gt;<br>
&gt; 2. What about future of sql backends? Are you going to focus on etcd<b=
r>
&gt; as main=C2=A0backend, or continue using sql, and leave etcd as an opti=
on?<br>
&gt;<br>
<br>
It was meant to be an option, not an replacement. However, nothing is<br>
cast in stone in the real world, even changes to technically worse<br>
solutions are very common in the IT world (unfortunately), due to<br>
various reasons.<br>